Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt

Use this file to discover all available pages before exploring further.

This page is the public registry of parties publishing artefacts under the AlgoVoi-authored canonicalisation discipline urn:x402:canonicalisation:jcs-rfc8785-v1, normatively specified in IETF Internet-Draft draft-hopley-x402-canonicalisation-jcs-v1 (Independent Submission, Informational; AlgoVoi-authored). The registry is maintained by AlgoVoi as a neutral record of observed adoption. Inclusion is informational and reflects public adoption only; it does not imply endorsement or normative authority from the listed party. Absence from the registry is not normative. The registry parallels the Appendix C “Known Adopters” section maintained in the IETF I-D revisions. The registry is the canonical web-accessible record between I-D revisions.

​
Why a public registry

Adoption of a canonicalisation discipline is the load-bearing evidence that the discipline works across independent implementations and use cases. A retained byte-deterministic record of who has adopted, when, and against which canon_version pin is itself audit-grade evidence:
  • For year-N auditability: a verifier reading retained receipts can confirm the adopters that were emitting under the same canonicalisation pin at the time of emission.
  • For ecosystem clarity: downstream parties evaluating whether to adopt benefit from observing existing adopter surfaces and their interoperability records.
  • For authorship attribution: the registry records each adopter’s own authorship of the artefacts they publish, alongside their dependence on the underlying canonicalisation discipline. Authorship of artefacts and authorship of the discipline are separate facts; the registry records both cleanly.

​
Registry

AdopterIdentifierSurfaceAnchorFirst observedEvidence
AlgoVoi (substrate author)api.algovoi.co.uk · docs.algovoi.co.uk · chopmob-cloud GitHub orgProduction gateway emitting all 5 AlgoVoi-authored receipt and response formats; 5 reference implementations on PyPI and npm; 8-implementation cross-validation matrix (Python, TypeScript, Go, Rust, Java, PHP, .NET, Ruby)canon_version: jcs-rfc8785-v1 across compliance, settlement, cancellation, refund receipts and composite-trust-query responses2026-04-12 (first production commit on compliance.py)All AlgoVoi-authored I-Ds and reference implementations linked from Substrate Authorship and Provenance
Supership / Crest Deployment Systems (Andy Salvo)andysalvo · verify.crestsystems.ai · supership.crestsystems.aiTwo URN extensions under the Crest namespace: (1) service_trust_v0 conformance vector set (downstream-adopter vector set anchored to the canonicalisation discipline); (2) urn:crest:trust-check-v1 general-service-trust envelope (JCS RFC 8785 + Ed25519 + content-addressed query_ref/response_ref + typed evidence array + informative-null taxonomy, hosted at supership.crestsystems.ai indexing 47K+ services)canon_version: jcs-rfc8785-v12026-05-23 (service_trust_v0 vectors merged into AlgoVoi corpus); 2026-05-25 (urn:crest:trust-check-v1 adopter-acknowledged)PR #1 in chopmob-cloud/algovoi-jcs-conformance-vectors · x402#2299 trust-check-v1 envelope · action-ref-verify repo
PEAC Protocolpeacprotocol/peacap2-open-mandate-hash fixture set — three positive scenario-shaped cases (baseline / budget-bound / expiry-bound) plus two composition-failure cases (non-SHA-256 digest, non-JCS canonicalisation). Consumes the AlgoVoi-authored open_mandate_hash v0 derivation; records mandate references in signed interaction records without modifying AP2 semantics.canon_version: jcs-rfc8785-v1 (via the AP2 OMH v0 derivation it anchors against)2026-05-25 (fixtures observed and self-declared as downstream adoption on google-agentic-commerce/AP2#265)specs/conformance/interop/ap2-open-mandate-hash/
The registry is observed at the time of the most recent revision below. Adopters present at observation but not listed above are invited to submit an entry via the process in the next section.

​
Adopter authorship principle

Adopters publishing vector sets, receipt-format extensions, or production artefacts under the canonicalisation discipline retain authorship of their own work. The registry records the adoption fact, not co-authorship of the underlying discipline. The discipline itself is AlgoVoi-authored under sole authorship. Substrate authorship history is catalogued at Substrate Authorship and Provenance. This separation is deliberate. An adopter publishing (say) a new vector set anchored to canon_version: jcs-rfc8785-v1 is the author of that vector set; AlgoVoi is the author of the canonicalisation discipline the vector set anchors to. Both facts are recorded; neither displaces the other.

​
How to submit an adoption entry

To be listed in the registry, an adopter MUST publish at least one artefact that pins canon_version: jcs-rfc8785-v1 in-band, in a publicly-citable surface (GitHub repository, package registry, IETF I-D, hosted public endpoint). Once published, submit via one of the following paths:
  1. Pull request against chopmob-cloud/docs, editing this page (adopters.mdx) to add a row.
  2. GitHub issue at chopmob-cloud/algovoi-jcs-conformance-vectors/issues titled Adopter registry submission: {your-identifier}.
  3. Email to chopmob@gmail.com with subject Adopter registry submission and the row fields below.
Required fields:
  • Adopter: human-readable name of the publishing party.
  • Identifier: a stable public identifier (DNS name, GitHub handle/org, DID URI, IETF author surname).
  • Surface: what is published (vector set, reference implementation, hosted endpoint, I-D, production service).
  • Anchor: the specific canon_version value pinned by the surface (currently jcs-rfc8785-v1).
  • First observed: ISO-8601 date the surface first published the anchor.
  • Evidence: at least one URL pointing to the publicly-citable artefact.
Submissions are validated by AlgoVoi against the artefact’s canonical bytes. The registry records whatever the artefact emits in-band; in particular, the registry does NOT validate the artefact’s correctness against any vector set or specification, only that it pins the canonicalisation discipline.

​
Withdrawal

An adopter MAY request removal at any time by the same submission paths. Withdrawn entries are not deleted but moved to a “Withdrawn (historical record)” section below to preserve the year-N audit history of the registry itself. The audit-chain of registry edits is recorded in the git history of chopmob-cloud/docs.

​
Withdrawn (historical record)

None at this revision.

​
Machine-readable mirror

A machine-readable JSON-LD mirror of the registry is maintained alongside this page at docs.algovoi.co.uk/adopters.json for automated consumption by composite-trust-query verifiers and downstream tooling.

​
See also