IPFS Grant Metadata Storage Proof-of-Concept

[apbendi]

This issue is a spec for a proof of concept/prototype implementation of storing Metadata on IPFS via Fleek. It's meant to demonstrate the end-to-end functionality, without including all details, such as the full Grant Schema, the ability to edit, or viewing past edits of the metadata. All such functionality can be added in future tasks once this proof of concept is built out.

Create Grant Flow

• Update the /dgrants/new form to remove the Metadata URL field, and replace it with two new fields: Name & Description
• When the user submits the form via "Create Grant":
  • Add the name & description to a JSON object with corresponding keys, encode this JSON as a file, and add it to IPFS via Fleek (more below)
  • Publish the IPFS CID generated above as the metadata ptr property when creating the GrantRound via transaction
    • 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. In other words, if the content hash is QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy, should the metaPtr be simply "QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy" or should it be something like "https://cloudflare-ipfs.com/ipfs/QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy"
    • Answer: see here

Grant Display

Update various places where Grant Metadata is displayed to actually load the data and show, specifically:

• Update /dgrants to show the Grant Name & (possibly shortened) Description in each Grant Card; remove the Grant ID and mtaptr URL
• Update /dgrants/:id to show Grant Name & Description, remove metadata URL and Grant ID

Sample JSON Object (partial schema for this initial implementation)

{
    "name": "My Grant Name",
    "description": "This is my Grant. There are many like it, but this one is mine."
}

Fleek API

• Use the ipfs-http-client package
• Use the Fleek endpoint with the api key for authentication as such:

import { create } from 'ipfs-http-client'

const ipfs = create({
  url: "https://ipfs-api.dev.fleek.cool",
  headers: {
    Authorization: "v2 <apiKey>", // or Bearer <JWT> or public <AppKey>
  },
});

• Use ipfs.add to add and pin the data, and get back the new CID
• Use ipfs.get to fetch the content hash

Add to grant bootstrap

• make sure that when grants are created locally that their content is properly linked

[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".