IPFS Grant Metadata Storage Proof-of-Concept about dgrants

[frankchen07]

Is the Grant Metadata storage part of the convenience layer that @phutchins talks about, or is it the convenience layer itself?

[mds1]

Question: should we publish only the CID, and let the frontend presume this is an IPFS hash and fetch it from whichever gateway it chooses, or should we publish a full URL, specifically the URL to this IPFS data via a particular IPFS gateway that we choose

Does the dgrants spec require that IPFS is used for metadata, or is that just a detail of our implementation here?

• If IPFS is required, then just a hash is sufficient. It will be cheaper to set, the contract can verify the length + Qm prefix, and frontends can resolve it with the gateway of their choice
• If IPFS is not required, then a fully qualified URL might be preferable. However a good frontend should still be able to check if the URL contains an IPFS CID so it can try a different one if the specified one is down

[apbendi]

After some discussion, the decision was:

• Store a gateway URL, rather than just a CID, to keep the contract generalized
• At the same time, in the app itself, verify that the URL provided is the Gateway we expect before executing an HTTP request, for security, privacy, and data integrity reasons. If the URL is not to the Gateway we expect, we can skip the Grant, and/or show a message like "unsupported grant metadata source".