ucan-wg
Add helper to get canonical JSON collection
Summary
Problem
UCAN at version 0.10.0 no longer inlines proofs, instead referencing them by CID. This change makes UCANs more compact, but proofs are less immediately accessible.
Impact
Debugging a proof chain is more difficult.
Solution
Add a helper that returns a canonical JSON collection (https://github.com/ucan-wg/spec#71-canonical-json-collection).
The collection may be incomplete if some of the proofs are not accessible. That's fine, because it indicates that bounds of proof that are immediately available.
@bgins thanks for opening this ticket.
Can we perhaps frame the issue in terms of the desired debugging modality?
I'm open to the idea that a canonical JSON collection is the right answer, but it's difficult to say for sure because debugging is a broad-ranging exercise. Where is the debugging taking place? What is the information you are trying to infer about the proof chain? Is stable content address-ability of the collection a concern?
And, just to allay any concern that this is an issue of spec compatibility, the spec text reads:
Multiple UCANs in a single request MAY be collected into one table. It is RECOMMENDED that these be indexed by CID. The canonical JSON representation (below) MUST be supported.
My read of this is that the use of such a collection is specifically to afford sending many (perhaps only implicitly related) UCANs in a single request. To use it in any other context (e.g., debugging) would be discretionary, and so should be a decision based on the merits of this format as they pertain to the use case.
Capturing some discussion from chat earlier today.
Can we perhaps frame the issue in terms of the desired debugging modality?
The use case I have in mind is the UCAN validator (https://ucan.xyz/validator/). The current implementation (at v0.8.1) relies on inlined proofs. Now that the spec pushes proofs out of the UCAN, users will need to input proofs into the validator.
Entering a canonical JSON collection would be a convenient way for users to input proofs. We also plan to support entering one proof token at a time (where we would discover the CID and whether the token proves anything), but this is less convenient than inputting a canonical JSON collection.