search

digitalbazaar / jsonld.js

A JSON-LD Processor and API implementation in JavaScript
https://json-ld.org/
Other
1.66k stars 195 forks source link

init ipfs in default document loader #513

Open F-Node-Karlsruhe opened 1 year ago

F-Node-Karlsruhe commented 1 year ago

Simple IPFS support in the default document loader with origin https://github.com/digitalbazaar/jsonld.js/issues/512

Could be improved with the use of multiple public gateways and Promise.any() as shown in the issue above.

F-Node-Karlsruhe commented 1 year ago

Example with W3C credential context:

ipfs://QmcpYBo2zpfSKdBAqY8HPSoBhEoVAb1WjPP2muehvYcCgs -> https://ipfs.io/ipfs/QmcpYBo2zpfSKdBAqY8HPSoBhEoVAb1WjPP2muehvYcCgs

dlongley commented 1 year ago

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

nklomp commented 1 year ago

I think it would be nice if you could optionally provide your own IPFS host, with the current value as default.

F-Node-Karlsruhe commented 1 year ago

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 Promise.any() like so would be desirable, but may be too much for the core/default document loader.

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.

F-Node-Karlsruhe commented 1 year ago

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 :)

dlongley commented 1 year ago

@davidlehn can we get your thoughts here? I think we would like this functionality, it's just a question of how it's done.

nklomp commented 1 year ago

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.

ntn-x2 commented 1 year ago

Hello! Has there been any progress lately on this PR? Checking in because of https://github.com/OwnYourData/didlint/issues/3, which results in our DID method (did:kilt), not being properly verified by the DIDLint tool. We saw that replacing IPFS links with any HTTP-based gateway (e.g., ipfs.io), correctly verifies the document structure.

F-Node-Karlsruhe commented 1 year ago

Example with W3C credential context:

ipfs://QmcpYBo2zpfSKdBAqY8HPSoBhEoVAb1WjPP2muehvYcCgs -> https://ipfs.io/ipfs/QmcpYBo2zpfSKdBAqY8HPSoBhEoVAb1WjPP2muehvYcCgs

Based upon the IPFS native url scheme resolving towards an HTTP IPFS gateway

F-Node-Karlsruhe commented 11 months ago

I think it would be nice if you could optionally provide your own IPFS host, with the current value as default.

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