Graph improvements; into the multichainverse

[bitbeckers]

A place to discuss what we can do to improve the Graph. Since we're pushing the SDKs and marketplace everywhere this week, I think we can work on improving the Graph starting next week.

The most obvious issue is that we can't support x-chain instances since

1. the SDK connects to a single Graph.
2. the SDK requires a user to connect to determine which Graph to show
3. graphIDs are in theory overlapping. This can be managed but is more clean to manager on the Graph itself.

Additionally we can implement IPFS in the Graph for faster loading of hypercerts data.

The SDK connects to a single Graph

For 1, since we're using urql, we can add an exchange that splits routes:
example 1
example 2

Then, we can let the client query endpoints by mapping over the supported chainIDs.

The SDK requires a user to connect to determine which Graph to show

When we have that implemented, we can work on 2 by separating "test" and "production". This would allow a user to connect in readOnly mode for test or prod using:

const client = new HypercertClient("test") with a log warning that this is readonly

const client = new HypercertClient(chain: { id: 11155111}) defaults to test but should block tx calls on non-11155111 hypercerts

To identify those hypercerts, we will update the hypercert IDs.

Graph IDs are overlapping

Currently the hypercerts ID is a concatenation of {contractAddress}-{tokenID}. We could update this to {chainId}-{contractAddress}-{tokenID}, with chainID being human readable integers (e.g. 11155111).

We can work on refactoring the IDs and connecting to multiple Graph instances at the same time. The are both requirements for "test" and "production" instances of the SDK.

@Jipperism could you provide some feedback?

[ryscheng]

Ya the GraphIDs being overlapping is a problem. I think prefixing with chainID is a reasonable way to disambiguate, I just hope the migration to that new format isn't too painful

As far as supporting multi-chain, what do you think about (1) just having multiple clients (one per chain) vs (2) supporting a single client connecting to multiple chains?

[Jipperism]

Another thing to consider is the conditionally disabling/enabling of lots of buttons in the frontend, depending on which chain you are connected to, as reading for different chains is possible but write operations will only be available for the chain currently connected to. Then we would have to display the chain on hypercerts as well, to prevent confusion.

[bitbeckers]

@Jipperism could you help refine that on the FE/Plasmic level? Since these changes need to propagate in the frontend we also should consider a flow where we have a develop environment that breaks production. This bring us back to figuring out to to separate dev from prod in Plasmic.

[bitbeckers]

#1059

[Jipperism]

Went through the hypercerts.org frontend to get an overview of what we would need to update:

/app/dashboard

• 'claim all fractions' button should select only hypercerts on the current chain to claim. but to avoid confusion we would probably want to show allowlist entries from all chains. that would mean adding some sort of tag/banner to the list entries to display which chain they are on, and possibly make them greyed out so it's clear they won't be minted when pressing the button.

/app/gallery-all

• display a chip/banner on every tile to make it clear what chain the hypercert lives on.

/app/create

• display chain in minting confirmation. this should be obvious already, but as it will become more of a cross-chain users will probably be less aware of what chain they're on so it might be useful to add some sort of extra warning.

/app/view?claimId=?

• split, merge, transfer button should be disabled if current chain is not the same as the chain the hypercert lives on.

Then there is probably some stuff that needs to be updated in supabase, as there are a lot of id's stored there. We usually save the chain Id so probably just a simple scripts that loops and updates the id by concatenating those.

I can't access plasmic right now so not entirely sure how much of the data fetching would have to be updated, but to get everything working I would expect this to be at least a day of work.

[bitbeckers]

@Jipperism did you manage to get access to Plasmic? The biggest blocker to resolve I see right now is to have a clear plan on how to not break everything since Plasmic is the component that only has one instance.

[Jipperism]

+1 for adding IPFS integration to the graph. The current solution won't scale at all for any operations with regards to filtering/sorting, as you'd have to pull in metadata for all hypercerts separately.

[bitbeckers]

See #1269 for the issues that are starting to emerge with the gateways. As far as we know, the Graph endpoints don't have this issue. So instead of shooting for hail across three gateways, we're at the point of needing to provide metadata via a 'cache' that we provide. The Graph is the prime candidate here.

Creating a separate issue for this, here's a good guide on the steps to take: https://blog.developerdao.com/how-to-properly-request-json-metadata-stored-in-ipfs-for-your-the-graph-subgraph

[bitbeckers]

#932