dacs-directory scan: revocation-marker predicate dacs1-revoked: vs colon-free on-chain program names — provenance question + a shape-detection suggestion
Pinned @ 07a008a. scan.ts:195:
} else if (name.startsWith("dacs1-revoked:")) {Verified facts. (1) That predicate matches a colon-bearing prefix. (2) DACS-Standard #238 (merged) makes storageProgramName implementation-defined, colon-free, and opaque — a conforming Demos write cannot carry a colon in its program name. (3) At least one conforming producer exists in the wild whose markers this predicate cannot match: a live testnet revocation at stor-d96b1a41cee0ec624e936efda59f33df680685f6 with program name dacs1-revoked_key%3A…_test-registration-walkthrough-1_v1 (underscore-joined; same convention as its listing's anchoring).
Open question, not an assertion: what is name's provenance at that line — the on-chain storage-program name, or a field from another discovery surface? If the former, the predicate cannot fire on conforming writes; if the latter, this is a naming-only observation. (Deliberately not calling it dead code without that answer.)
The deeper point, independent of the answer: per #238, a consumer shouldn't treat storageProgramName as a standardized encoding of the logical address at all — even an underscore-corrected match would only cover producers who happen to share this one convention; another conforming producer may hash or randomize. The durable fix appears gated on the normative question cross-linked below (markers currently have no binding-publication mechanism). Interim suggestion that fits the indexer's existing architecture: the README already describes content-shape detection as a discovery channel, and the marker payload has a distinctive closed shape ({listingId, listingVersion, listingContentHash, revokedAt, reason?, signature} + the dacs-revocation:v1: domain) — shape-detecting the value sidesteps program-name assumptions entirely.
Scope note: this concerns the scan/discovery channel only; revocation checking for already-indexed listings (hasValidListingRevocation) may resolve addresses by a different path and isn't asserted defective here.
Filed as an issue rather than a PR because the right fix depends on the spec question — happy to PR the shape-detection (or whatever lands) once direction is confirmed.
dacs-directory scan: revocation-marker predicate
dacs1-revoked:vs colon-free on-chain program names — provenance question + a shape-detection suggestionPinned @
07a008a.scan.ts:195:Verified facts. (1) That predicate matches a colon-bearing prefix. (2) DACS-Standard #238 (merged) makes
storageProgramNameimplementation-defined, colon-free, and opaque — a conforming Demos write cannot carry a colon in its program name. (3) At least one conforming producer exists in the wild whose markers this predicate cannot match: a live testnet revocation atstor-d96b1a41cee0ec624e936efda59f33df680685f6with program namedacs1-revoked_key%3A…_test-registration-walkthrough-1_v1(underscore-joined; same convention as its listing's anchoring).Open question, not an assertion: what is
name's provenance at that line — the on-chain storage-program name, or a field from another discovery surface? If the former, the predicate cannot fire on conforming writes; if the latter, this is a naming-only observation. (Deliberately not calling it dead code without that answer.)The deeper point, independent of the answer: per #238, a consumer shouldn't treat
storageProgramNameas a standardized encoding of the logical address at all — even an underscore-corrected match would only cover producers who happen to share this one convention; another conforming producer may hash or randomize. The durable fix appears gated on the normative question cross-linked below (markers currently have no binding-publication mechanism). Interim suggestion that fits the indexer's existing architecture: the README already describes content-shape detection as a discovery channel, and the marker payload has a distinctive closed shape ({listingId, listingVersion, listingContentHash, revokedAt, reason?, signature}+ thedacs-revocation:v1:domain) — shape-detecting the value sidesteps program-name assumptions entirely.Scope note: this concerns the scan/discovery channel only; revocation checking for already-indexed listings (
hasValidListingRevocation) may resolve addresses by a different path and isn't asserted defective here.Filed as an issue rather than a PR because the right fix depends on the spec question — happy to PR the shape-detection (or whatever lands) once direction is confirmed.