init ipfs in default document loader #513
Conversation
|
Example with W3C credential context:
|
There was a problem hiding this comment.
Hmm -- so at first glance at the PR title my thought was "We want to support IPFS but not in core." But looking at this PR, there's really not a whole lot here to make it happen.
@davidlehn what are your thoughts?
|
@davidlehn, also, if we do want to accept this PR, I recommend we should reconsider adding the URL itself (or at least the beginning of it if it's huge) to the error message string itself (I know it's already in the details) -- as that has been a common complaint since those details are often not surfaced cleanly in various tools. |
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
|
I think it would be nice if you could optionally provide your own IPFS host, with the current value as default. |
That would be great. In my opinion an semi-custom array along with The proposed implementation might be just enough. A custom gateway is not necessarily needed due to the discoverability of content within the IPFS network; allowing to fetch content from your custom node through an arbitrary gateway. This might rather be integrated in one's own custom documentLoader. |
We are publishing JSON-LD contexts for verifiable credentials to IPFS https://github.com/european-epc-competence-center/vc-verifier digitalbazaar/jsonld.js#513
|
Should i further develop this PR to make it more sophisticated in order to merge or will you implement the feature from scratch in the next iteration anyway? We are using IPFS for context quite a lot already and it would be really convenient to have the resolution embedded in the standard library :) |
|
@davidlehn can we get your thoughts here? I think we would like this functionality, it's just a question of how it's done. |
|
Imo for VCI it should be pretty clear if you look at the spec and want something like this. Start with the issuer url in the DID doc, and follow normal OID4VCI discovery from there. You are making sure that the issuer and well-knowns are served from the same origin this way. Our lib will not work if that is not the case, and we certainly wouldn't be adding something where well-knowns potentially might be served from different origins. |
|
Hello! Has there been any progress lately on this PR? |
Based upon the IPFS native url scheme resolving towards an HTTP IPFS gateway |
True that. The ipfs.io gateway has not been very reliable recently. One should carefully choose the default/s https://cloudflare-ipfs.com seems to be a good choice as well Btw. curl has released support for IPFS already https://curl.se/changes.html#8_4_0 |
Simple IPFS support in the default document loader with origin #512
Could be improved with the use of multiple public gateways and
Promise.any()as shown in the issue above.