Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add helper to get canonical JSON collection #109

Open
bgins opened this issue Jun 9, 2023 · 2 comments
Open

Add helper to get canonical JSON collection #109

bgins opened this issue Jun 9, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@bgins
Copy link
Contributor

bgins commented Jun 9, 2023

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 bgins added the enhancement New feature or request label Jun 9, 2023
@cdata
Copy link
Member

cdata commented Jun 9, 2023

@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.

@bgins
Copy link
Contributor Author

bgins commented Jun 9, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants