A problem identified in GRT Curation Station is that there isn’t a way for subgraph developers and consumers to easily search subgraphs by the contracts they index, which is especially important information to have access to from the decentralized network. A consequence of this has been superfluous expenditures in the form of both time and transaction fees, spent developing and then deploying subgraphs with functionality similar or identical to existing subgraphs.
This dApp queries a subgraph which pulls IPFS manifests from onchain subgraph deployments, extracting contract addresses and events which it then associates with subgraph deployments for easy searchability. To enhance search UX, the subgraph also uses stripped-down subgraph, version, and deployment indexing functionality from the Graph Network Subgraph; this also provides for smooth navigation between contract and subgraph data on the frontend.
Possible future work includes:
Integration of ENS Names
More accurate computation of subgraph signals which inform the ordering of search results
Subgraph contract/event correlation: “This subgraph is most similar to…”
Subgraph-friendly YAML parsing library
Crawling dependency trees from IPFS manifests for other potentially relevant information
Hi @Michael-L this is great! @juanmardefago I wonder if this kind of metadata could also be surfaced in the main Graph Network subgraph? @Michael-L would you be open to contributing some of the parsing / entity logic there?
The IPFS enabled network subgraph already does some light parsing of the IPFS files (mostly to index the targeted network from the subgraph deployment), so it could be possible to add more metadata parse logic to it (unsure of the performance impact though).
Hi @adamfuller, the contract and event metadata are a pretty simple integration into the network subgraph. I forked the repository this evening and am in the process of testing the changes.
@juanmardefago it’s more computationally complex than the current IPFS metadata parsing and the logic might benefit from optimization, but the function is called less frequently.
Just took a quick glance at the code, and given the concern is well defined and isolated, it should be almost trivial to integrate to the existing codebase.
It does look like it shouldn’t be a performance constraint, since it’s only really called in 3 (non-frequent) events, and would improve the core subgraph feature set.
Do you want to do a PR for it? (I can do it if you don’t have the time, just asking since it’d be cool for you to be the author of it )
@adamfuller@juanmardefago I’m not sure how to add reviewers, but I created a pull request earlier this week. Please let me know if I should make any revisions.
)