Problem
Following #18, the RenderTemplate2024 interface in this package now accepts a digestMultibase field, but constructRenderMethod only stores the value when callers pass it in via extra. Every consumer that wants the integrity field has to compute the multibase-encoded multihash themselves before calling the library, duplicating the work and the algorithm/encoding choices across consumers.
Current Behaviour
constructRenderMethod(template, RenderMethodType.RenderTemplate2024, { url }) returns a RenderTemplate2024 without a digestMultibase unless the caller has pre-computed and supplied one in extra. Consumers that want the field must implement their own multihash + multibase pipeline against a hashing library, decide on an algorithm and encoding, and remember to call it on every construction path.
Expected Behaviour
The library exposes:
- A primitive
generateDigestMultibase(content, opts?) that returns a multibase-encoded multihash string. Defaults to sha2-256 and base58btc (the conventional UNTP / W3C VC choices), with both configurable.
- An async constructor
constructRenderMethodAsync that mirrors constructRenderMethod but auto-fills digestMultibase for RenderTemplate2024 outputs when:
- the caller supplied a
url in extra (the signal that the template will be hosted remotely),
- the caller did not pre-supply a
digestMultibase (caller-supplied values are preserved verbatim), and
- the source
template is non-empty (there is content to hash).
The synchronous constructRenderMethod is unchanged so existing callers continue to work without modification.
Gating rationale: digestMultibase is only useful when the template is hosted remotely. For inline templates the signed credential already covers the template bytes, so emitting a digest there is at best redundant and at worst a footgun if the inline content and the recorded digest drift.
Both new exports build on the newly published @uncefact/untp-utils MultibaseDigest primitive so the algorithm and encoding choices live in one place across the UNTP ecosystem.
Related to #18.
Closed by #25.
Problem
Following #18, the
RenderTemplate2024interface in this package now accepts adigestMultibasefield, butconstructRenderMethodonly stores the value when callers pass it in viaextra. Every consumer that wants the integrity field has to compute the multibase-encoded multihash themselves before calling the library, duplicating the work and the algorithm/encoding choices across consumers.Current Behaviour
constructRenderMethod(template, RenderMethodType.RenderTemplate2024, { url })returns aRenderTemplate2024without adigestMultibaseunless the caller has pre-computed and supplied one inextra. Consumers that want the field must implement their own multihash + multibase pipeline against a hashing library, decide on an algorithm and encoding, and remember to call it on every construction path.Expected Behaviour
The library exposes:
generateDigestMultibase(content, opts?)that returns a multibase-encoded multihash string. Defaults tosha2-256andbase58btc(the conventional UNTP / W3C VC choices), with both configurable.constructRenderMethodAsyncthat mirrorsconstructRenderMethodbut auto-fillsdigestMultibaseforRenderTemplate2024outputs when:urlinextra(the signal that the template will be hosted remotely),digestMultibase(caller-supplied values are preserved verbatim), andtemplateis non-empty (there is content to hash).The synchronous
constructRenderMethodis unchanged so existing callers continue to work without modification.Gating rationale:
digestMultibaseis only useful when the template is hosted remotely. For inline templates the signed credential already covers the template bytes, so emitting a digest there is at best redundant and at worst a footgun if the inline content and the recorded digest drift.Both new exports build on the newly published
@uncefact/untp-utilsMultibaseDigestprimitive so the algorithm and encoding choices live in one place across the UNTP ecosystem.Related to #18.
Closed by #25.