Currently, metaPtrs on Grant Rounds and Grants are stored as full URIs, which are then fetched by the client to obtain the data after the pointer itself is read from the chain. While we currently use IPFS for this data, via Fleek, the URI could in theory be any http endpoint.
A number of issues with this have become clear over time.
Trust/CORS/performance issues that come from fetching data from arbitrary endpoints
Flexibility to change how data from certain protocols is fetched. Importantly, when we attempted to switch endpoint for the IPFS proxy, we quickly realized all existing Grant metadata would have to be updated to do this correctly.
One naive solution would be to change the spec to instead store only the IPFS CID, and allow the client to fetch this data through any source it preferred. The obvious downside here is the lock in to IPFS— what if we want to support other protocols (Filecoin, Arweave, IC, etc...) in the future for metadata storage?
In order to avoid these issues, while also being flexible for the future, we'll update the definition of a metaPtr. We can store two values as a Tuple: (uint kind, bytes identifier).
kind will be a de facto Enumerated type, defined externally as part of the protocol spec, defining the kind of decentralized storage that is being used. For now, the only valid kind value will be 1 for IPFS. (0 should be reserved as a none/invalid metaPtr to avoid mistaking an unset metaPtr as some protocol).
identifier will be whatever data is needed for the protocol defined by this code, the definition of which will also be considered part of the dGrants spec. For the IPFS case, it will be defined as the CID of the metadata to be fetched.
This change will require changes to the contracts and to the frontend. It needs to be implemented for Grants, Grant Rounds, AND the sub-metaPtrs to image data stored in the metadata itself. In the latter case, the same Tuple structure should be used, just as an element in the metadata JSON:
Currently, metaPtrs on Grant Rounds and Grants are stored as full URIs, which are then fetched by the client to obtain the data after the pointer itself is read from the chain. While we currently use IPFS for this data, via Fleek, the URI could in theory be any http endpoint.
A number of issues with this have become clear over time.
One naive solution would be to change the spec to instead store only the IPFS CID, and allow the client to fetch this data through any source it preferred. The obvious downside here is the lock in to IPFS— what if we want to support other protocols (Filecoin, Arweave, IC, etc...) in the future for metadata storage?
In order to avoid these issues, while also being flexible for the future, we'll update the definition of a metaPtr. We can store two values as a Tuple:
(uint kind, bytes identifier).kindwill be a de facto Enumerated type, defined externally as part of the protocol spec, defining the kind of decentralized storage that is being used. For now, the only validkindvalue will be1for IPFS. (0 should be reserved as a none/invalid metaPtr to avoid mistaking an unset metaPtr as some protocol).identifierwill be whatever data is needed for the protocol defined by this code, the definition of which will also be considered part of the dGrants spec. For the IPFS case, it will be defined as the CID of the metadata to be fetched.This change will require changes to the contracts and to the frontend. It needs to be implemented for Grants, Grant Rounds, AND the sub-metaPtrs to image data stored in the metadata itself. In the latter case, the same Tuple structure should be used, just as an element in the metadata JSON:
When data is fetched in the frontend, it should simply:
kindis 1, and fail if notAdditional note:
Open to alternative name suggestions for both
kindandidentifier