This chapter explains how, after the Root platform has formed publication facts, resource packages, DID documents, metadata, hashes, credentials, and publication proofs are propagated through the content distribution platform to authorized Discovery nodes. The chapter distinguishes the states of publication tasks, propagation materials, synchronization cursors, receipt validation, and local indexing, and explains how batch transfer, retries, partial failures, idempotency, and recovery keep propagation traceable. The fact that content can be retrieved must not be mistaken for the fact that the resource has been applied by every Discovery node.

10.1 Distribution Model and Content Categories

Content distribution follows the model of “publication facts are formed first, propagation materials are transferred afterward, and Discovery nodes validate again.” The propagation set for a resource version usually includes the resource package (ResourcePackage), DID document, resource metadata, hashes, registration credential, Root-verified ResourcePackage, lifecycle status, authorization domain, and necessary summaries or index hints. A summary may improve synchronization efficiency, but it cannot replace validation of the complete resource package and proofs.

There are three types of objects that are easily confused in the propagation path: the Root platform creates publication tasks and publication cursors, the content distribution platform stores retrievable resource materials, and Discovery nodes convert validated materials into local indexes. They respectively represent “what the Root platform decides to propagate,” “where the content can be retrieved,” and “what a node has already applied.” The same resource DID may run through all three, but the three states must not be merged into one network-wide state.

10.2 Content Distribution Service Responsibilities

The content distribution platform is responsible for hosting, retrieving, batch-transferring, caching, and reporting the transfer status of publication materials. A content distribution publisher can obtain publication tasks from the Root platform, organize resource packages according to the publication cursor, write them to the content distribution platform, and report successful or failed results back to the Root platform. This service does not create resource control rights, node authorization, or Root-verified ResourcePackage; Discovery nodes must still decide whether to apply materials based on their own validation results.

The current reference implementation’s batch publication response contains published items, failed items, and the corresponding publication cursor. A publisher confirms the result of a batch only when the response is parseable and the number of items is consistent with the request. If a request succeeds but the response lacks a cursor or contains incomplete item statuses, it must be handled as an exception rather than being treated as confirmation that the entire batch has been published.

10.3 Distribution Manifest and Publication Checkpoints

The publication manifest is the entry point through which a Discovery node determines the synchronization scope and validation objects. Publication checkpoints divide propagation state into sent, received, validated, and applied. The resource DID, package version, package hash, and publication cursor in the manifest associate a resource version; the target nodes and sequence range in a notification batch associate one propagation operation. A Discovery node may report that an item has been applied only after it has completed validation and written the item to its index.

10.4 Distribution of Resource Packages, Metadata, Proofs, and Index Data

10.4.1 Resource Package Distribution

The resource package is the primary complete payload for Discovery nodes. It must at least be associated with the publication manifest through the resource DID, resource package version, and package hash. The content distribution platform may provide a complete package or incremental materials according to the manifest, but the receiver must recompute the hash and validate the Root-verified ResourcePackage before writing the material to a trusted discovery index.

The current content distribution platform provides POST /cdn/resources as the single-item publication endpoint and POST /cdn/resources/batch as the batch publication endpoint. A single-item request is carried by ResourceCdnPublishRequest and contains ResourcePackage and upstreamAuth; a batch request is carried by ResourceCdnBatchPublishRequest and contains entries with publicationCursor and shared upstream authentication. A successful single-item response contains status: published, the resource DID, resource type, package version, and publicationCursor. A batch response additionally distinguishes acceptedCount, failedCount, successful items, and failed items. Batch HTTP success cannot be used as a substitute for every item having been applied.

Discovery nodes can use POST /cdn/resources/batch-get to read resource packages in batches by resource DID, or use the resource index endpoint to read incrementally by afterCursor. A batch read returns the requested count, hit count, and resource package items; an incremental index response returns items, count, afterCursor, nextCursor, and hasMore. These cursors serve batch reads, list pagination, and propagation synchronization respectively and cannot replace one another.

10.4.2 DID Document and Metadata Distribution

DID documents and resource metadata may be transferred together with the resource package, or retrieved separately by resource DID, version, and hash. When they are sent separately, a Discovery node must not apply one part while losing the association between the parts. If the DID document, metadata, and package-external summary are inconsistent, the node should reject the combination and record the missing or conflicting fields.

10.4.3 VC and Root Proof Distribution

The registration credential describes the registration fact established by the registration service node, while the Root-verified ResourcePackage describes the Root platform’s acceptance of a specific resource version. They should be transferred with associations to the resource DID, version, and hash. The receiver should separately validate the issuer, signature, coverage, and current status of each, and must not skip Root proof checks merely because a registration credential is present.

10.4.4 Index Data Distribution

Index data is a derived read model formed by a Discovery node from published materials. It may contain resource summaries, capability tags, endpoint references, lifecycle status, and freshness information. Index data must not be returned as a new Root platform fact. A Discovery node must be able to identify the publication cursor, validation time, and authorization domain corresponding to an index record.

10.5 Distribution-Boundary Integrity Validation

After receiving materials, a Discovery node should first validate the notification target, manifest scope, and payload structure, and then validate the resource DID, resource type, version, the three categories of hashes, Root-verified ResourcePackage, lifecycle, and authorization domain. Objects that fail validation must not be written to the trusted discovery index. A rejection record may be written for diagnosis and retry. Successful transfer with corrupted content is an integrity failure; missing material is a recoverable retrieval failure; a revoked governance status is a state failure that blocks application.

Negative acceptance tests at the receiver can independently change only the package content, the resource DID bound to the proof, or the authorization domain of the current Discovery node. In the first two cases, the receiver should reject the material respectively at the hash or proof-binding stage; in the third case, it should block index application. A failure may leave a record containing the resource DID, cursor, failure stage, and error code, but the affected synchronization cursor must not advance.

10.6 Version Freshness and Synchronization Cursors

The publication cursor describes the position of Root platform publication facts in the propagation path; the synchronization cursor describes the position already processed by a Discovery node; the resource version describes the version of the resource content itself; freshness describes the time relationship between publication or receipt and the current observation moment. They serve ordering, recovery, version selection, and latency explanation respectively, and one field cannot replace the others.

10.6.1 Synchronization Cursor

A synchronization cursor is maintained by a Discovery node to represent the content distribution position that the node has processed. Advancing the cursor must be conditional on the corresponding materials completing structural, hash, proof, and status validation. Advancing the cursor to a position does not mean that all resources after that position have been applied successfully.

10.6.2 Version Freshness

Version freshness should consider the Root platform publication cursor, resource package version, publication or update time, local receipt time, and index application time together. Time differences are used to explain propagation latency and must not alone determine version priority. Content selection for the same DID must still be based on a verifiable version, hash, and Root platform publication fact.

10.6.3 Expired Data Determination

A Discovery node should determine whether data is expired according to the permitted delay, governance status, and resource lifecycle. Ordinary information display may retain an old snapshot marked with freshness information. Before processing revocation, suspension, node authorization changes, or high-risk calls, if the latest status cannot be confirmed, the node should pause the sensitive action instead of continuing to use an unconfirmed old status.

10.6.4 Gap Compensation

When a cursor gap, discontinuous batch sequence, or missing resource material is detected, the node should pause cursor advancement for the affected scope, retrieve the missing content according to the manifest or update endpoint, and continue after revalidation. Before the gap is filled, the node may report synchronization lag but must not mark subsequent items as applied without evidence.

For example, if a node has applied cursor 100 and receives cursor 102 while 101 is missing, it may save the material for 102 as pending and report the gap, but its local “applied position” should remain 100. After retrieving and validating 101, it should process 102 in order. If 101 is explicitly rejected, it should retain a traceable rejection record and determine whether the cursor may cross that item according to the implementation. Receiving a larger cursor value alone is not sufficient to advance the cursor.

10.7 Initial Synchronization and Incremental Synchronization

10.7.1 Initial Full Synchronization

Initial synchronization should first obtain a verifiable publication manifest, starting cursor, and target authorization domain, and then retrieve resource packages and their proofs according to the manifest. The node should validate, persist, and apply each item to the index. After the entire scope is completed or every rejection has been explicitly recorded, it may report the synchronization result for that scope.

10.7.2 Incremental Synchronization

Incremental synchronization continues from the persisted synchronization cursor or notification-batch sequence, retrieves publication materials after that position, and processes them in publication order. Duplicate batches and duplicate resource packages should be processed idempotently. A new cursor may advance only after the corresponding items reach an applied or explicitly rejected state.

10.7.3 Synchronization Confirmation

Synchronization confirmation should distinguish at least received, validated, indexed, and externally queryable. Confirmation responses, logs, and database records should associate the target Discovery node, sequence range, successful or rejected items, current cursor, and last error. An HTTP request succeeding cannot substitute for confirmation that content has converged.

10.7.4 Recovery After Interruption

After a node restarts or the network is interrupted, it should recover from the last persisted cursor or incomplete batch, replay necessary materials, and process them according to idempotency rules. If the cursor is invalid, the manifest has changed, or governance status cannot be confirmed, the node should retrieve the manifest again or enter a review-pending state instead of skipping the missing interval.

10.8 Retry, Backoff, and Interruption Recovery

Retries apply only to recoverable transfer, timeout, service-unavailable, or temporary-lock failures. The publisher and Discovery node should retain the task or batch identifier, target cursor, processed items, retry count, and last error, and use backoff to avoid continuously impacting the upstream service. Invalid signatures, hash mismatches, resource-type errors, and authorization-domain mismatches are material or permission failures; they should be recorded and repeated infinite retries of the unchanged payload should be stopped.

A retry record should at least answer three questions: which resource version was retried, whether the failure occurred during retrieval, validation, writing, or result reporting, and what condition the next retry depends on. For batch processing, results should be updated separately for successful and failed items. A successful overall batch response must not cause already successful items to be applied again, and one failed item must not erase the processing evidence for other items. Repeated delivery of the same task should use the resource DID, version, hash, and publication cursor for idempotency checks.

10.9 Cache Behavior and Expired-Data Handling

10.9.1 Browser or Client Cache

A browser or client cache stores public materials, network snapshots, or resource summaries already retrieved by the page or client. It is not the authoritative publication record of the Root platform. Cache keys should include the interface scope, resource DID, or page-data version and other necessary context. Clearing browser data may remove the cache, but it does not affect the server-side publication fact. When reading cached data, the client should include the retrieval time, source, and freshness marker so that a local hit is not displayed as if it had just been confirmed by the network.

10.9.2 Node-Side Cache

The content distribution platform and Discovery nodes may cache resource packages or indexed read models that have passed the corresponding validation. The content distribution platform caches materials available for propagation, whereas a Discovery node caches query data after local application. Node-side caches should retain the resource version, package hash, publication cursor, and validation time, and replace entries in a verifiable order when updating. A cache must not bypass Root-verified ResourcePackage, resource-package hash, or current governance-status checks.

10.9.3 Preferential Display of Old Snapshots

When new page or query data has not yet been retrieved, the client may first display the most recently saved old snapshot whose source can be identified, while marking the snapshot time, data source, and possible synchronization delay. An old snapshot can improve the waiting experience for ordinary reads, but it is not suitable as the real-time basis for revocation, suspension, authorization changes, or high-risk calls. Snapshot display should be separated from background refresh status; the display time of old data must not be updated to the current confirmation time.

10.9.4 Background Refresh and Failure Degradation

After a background refresh succeeds, the client or node should complete structural, hash, proof, and status checks on the new materials and then atomically replace the old snapshot. When refresh fails, it should retain the old snapshot and record the failure reason, last successful time, and freshness. If the failure concerns revocation or the authorization status cannot be confirmed, the node should reduce the availability state or pause sensitive actions rather than unconditionally continuing to use the old snapshot. Refresh logic must not block basic page rendering or clear valid existing data on failure and thereby create unnecessary blank space.

10.10 Propagation Observability and Audit Records

Propagation audits should associate the resource DID, package version, package hash, publication task, publication cursor, notification batch, target Discovery node, send/receive/validation/application times, retry count, and error reason. The Root platform and publisher should be able to state which items completed content distribution; a Discovery node should be able to state which items were rejected or remain pending synchronization. These records trace the propagation process and do not change the original proof of the resource.

For batch propagation, both the overall batch result and each resource-item result should be recorded. An overall successful response does not mean that every item has been applied, and partial success must not erase the evidence of completed items. During operational troubleshooting, jobKey, request ID, and publication cursor can be used to associate Root platform tasks, content distribution platform history, and Discovery node synchronization records. These fields trace propagation and are not equivalent to a resource controller signature or governance authorization.

For batch propagation, both the overall batch result and each resource-item result should be recorded. An overall successful response does not mean that every item has been applied, and partial success must not erase the evidence of completed items. During operational troubleshooting, jobKey, request ID, and publication cursor can be used to associate Root platform tasks, content distribution platform history, and Discovery node synchronization records. These fields trace propagation and are not equivalent to a resource controller signature or governance authorization.

10.11 Publication Ordering and Conflict Resolution

Propagation order is based on the Root platform publication cursor and notification sequence. Resource-version selection is based on the resource package version, predecessor-version relationship, package hash, and Root-verified ResourcePackage. Duplicate batches containing the same materials should be processed idempotently. If different hashes appear at the same position, an old version attempts to overwrite a new version, or predecessor materials are missing, application of the affected scope should be paused and the conflict recorded. Materials must not be overwritten arbitrarily according to arrival time.

10.12 Distribution Consistency and Freshness Guarantees

Consistency metrics should separately state the scope that the Root platform has published, the scope available from the content distribution platform, and the scope received, validated, and applied by Discovery nodes. Freshness metrics should state the publication or receipt time from which they are calculated and the observation or application time to which they are calculated. Metrics must include the sample scope, failed items, and authorization-domain definition; success by one node or a cache hit cannot represent network-wide convergence.

10.13 Partial Failure and Recovery Semantics

Partial failures are isolated by resource item and target node. Items that have completed validation and application may advance their own state. Failed items should retain independent error, retry, and missing-material information, and must not be skipped because the overall batch response succeeded. During recovery, the node should first fill missing materials, then complete item-level validation and persistence, and finally advance the corresponding cursor or record an explicit rejection. Applied items are not rolled back merely because another item in the same batch failed, and failed items must not be hidden because an old snapshot remains available.

Final convergence requires every item in the target sequence range to reach “applied” or have a clear and traceable rejection record. If hashes, proofs, lifecycle, or authorization domains change during recovery, the corresponding validation process must be entered again. An old snapshot may be used only for limited read-side results marked with freshness information; it must not conceal revocation, suspension, or authorization changes.

References