Staged Plan for the Explorer Dapp

[davekaj]

Description

We are going in the direction of making the graph explorer a decentralized application. This requires removing any backend data base that we have, and putting it all on the blockchain, and decentralized file networks such as IPFS or eventually Filecoin. This will be a multi month process, as we do not want to mess with the current explorer, which is quite stable right now. We will be working on this on the side on a branch for a while, and slowly, when we are ready, we will merge it. We will have another website, apart from production and staging, maybe named demo or dapp or something like that.

Proposed Idea

We will take the basic idea of the GNS that exists, and modify it so that it can store all the data necessary to replicate what exists already. This is V1 feature parity with what exists there.

Then once that is working, we will start implementing the new features, like staking, curating, and everything.

We will store all necessary data on the blockchain (accounts, subgraphIDS). All metadata will be stored on IPFS for now, allowing it to be upgradeable easily and cheaply.

Proposed Implementation

• Ethereum used to store blockchain data
• IPFS to store meta data
• Truffle test framework for solidity
• All graph software to produce a subgraph
• Fit this all into the existing graph explorer front end, which uses react and apollo

Steps

V1 (POC with Feature Parity) ~ 2 weeks

• Complete update of GNS, without addressing open questions and research questions
• Complete IPFS metadata schemas
• Testing done on ganache
• Create subgraph to track GNS data
• Test the Subgraph
• Upload data to IPFS, and tie this into the explorer dapp

V2 (Research Stage) ~ 2 weeks

• Answer all open questions
• Research all research questions, and finalize the best option we have for each

V3 (Upgrading contracts, and building out the subgraph) ~ 4 weeks

• Go over these sections with team, look at designs, see what will be needed
• Update rewards if needed, and then implement it with the subgraph
• Update service registry if needed, and then implement it with the subgraph
• Update staking if needed, and then implement it with the subgraph
• Do multisig wallet and bancor bonding curve need anything? (likely just the bonding curve will have to be added into the UI)

V4 (Building the new graph explorer) ~ 8 weeks

• Branch off of graph explorer, start refactoring it to point to Ethereum Testnet data we have published
• Upgrades to smart contracts and subgraph as needed
• Test stability on testnet for a few weeks to a month

V5 (Launch) ~ 6 weeks

• Migrate existing data to the smart contracts
• Deploy contracts to testnet in a public manner
• Launch the dapp on staging, or whatever name we have, watch how it works on mainnet
• When confident, make the switch

Documentation

There will be no documentation made in V1, except for basic startup instructions
TODO - document along the way, and figure out who to do the documentation. It will center around the whole dapp experience.

Testing

Truffle will be used to test Solidity, and we will test this in tandem with the subgraph, so that we can see how the subgraph operates on a test net like ganache. Eventually testing it on one of the real Ethereum networks, and then finally push it to mainnet.

Open Questions

Open questions are general implementation questions, that don't necessarily need research

• Where will we store saved queries (IPFS?)
• How do we make our IPFS files truly available and decentralized? I would think we should force all files to be pinned to our node, as well as a few of the most used gateways, so we don't run into problems where it is hard to find our IPFS files, when not connected to our IPFS node, as was the case with Origin. And we want to avoid FOAMs case where their IPFS solution is a centralized cluster.
• What is everything that needs to be private? (personal contact information mainly)
• Will we run our own attestation service
• How will we implement Accounts, Users, and Organizations into an ethereum account structure? (RIGHT NOW I PROPOSE LET USERS DO ORGS ON THEIR OWN. I.E. DAOS)
• How does subgraph versioning work
• How do we ensure the IPFS schemas can't break the subgraph? (The JSON api needs to be robust around failures. It might already be, but I need to double check)

Research Questions

Research questions are questions that need research to do be before a confident answer can be given. Some of these may even be new areas of research for Dapps, that have unanswered questioned as of today

• What is the best way to create user accounts? Likely we want to follow a standard for ethereum accounts representing a user, with attestations. Origin worked on this, but punted to focus on their dapp. Bloom is worthy looking into. Other options exist as well. We need to somehow replace github Oauth, with the best blockchain based identity option out there
• When is filecoin available, and how do we plan to migrate to it (or something like it, but it is very highly likely that we choose Filecoin)
• Will we use metamask? Or can we avoid this with meta transactions? Or another solution?
• What is the best way to create private data on the blockchain. Such as account data or access tokens (three box)

[davekaj]

Good list of ERC standards we need to pay attention to - metacartel/Harbour-MVP#10

[nenadjaja]

We can potentially look into this https://fortmatic.com/ instead of MetaMask. It doesn't seem to integrate with ethers.js (which is what I was thinking of using instead of web3.js)

[davekaj]

This is out of date. closing