The decentralized approach of being a DAO member is to run API3 dashboard on your local machine. For that you will just need git and docker:
While this is the most secure and reliable way to use the DAO, many DAO members might not be comfortable with Git, Docker, or the command line.
An easier way for DAO members would be for API3 to package the dashboard as a desktop app that can be installed like any other desktop application. One way to do that is with Electron.
It looks like some have used Electron with dapps before. For example:
I doubt this would be a high priority for the core tech team but the work would be traditional web development work, not smart contract development. It could be an opportunity for traditional developers who want to contribute to API3.
Hey @ryan, this seems very necessary for DAO members who don’t have a tech background also!! I am part of one of the winning teams that participated in the Bitcoin Bankathon in El Salvador where API3 was part of the organizers, so we are very grateful to everyone who was involved in the organization of this event. Therefore, our team would like to participate and contribute in the development of this short project for API3.
Awesome! Glad to hear it. The goal is pretty straight-forward. Currently you can run the dashboard locally with Git and Docker as described in the Readme.
The goal is to provide a way to run the dashboard locally that DAO members who aren’t developers can easily do. My inclination is to try using Electron but if you can find a better way that’s fine too. It should:
Not require installing dev tools as a prerequisite
I attach the link to download version 0.1.0 of desktop daskboard. We would appreciate your opinions and suggestions to improve it.
Initially you can download the versions for Windows and Linux that are in the repository folders, and install it like any other software. At the moment to connect to your wallet you can only use Walletconnect and scan the QR code.
There is still work to be done to improve the user experience and customize it more, and update it to future updates of the original version. We need to test the Metamask integration also, it looks like this method described adove is not working.
I installed the Windows version on a VM because I use a Mac. It installed fine and I was able to connect MetaMask Mobile with WalletConnect - no problem. But it doesn’t seem to load the DAO data after that. It shows my wallet is connected but the dashboard shows that it’s still loading.
Since this isn’t creating a new app, it’s just making the existing app work in Electron, I don’t have any suggestions to improve it. It either works or it doesn’t. Does it load the DAO info for you after you connect your wallet? Has anyone else has a chance to try it?
My only suggestion would be to build a Mac installer as well but that can be done after everything else is figured out. MetaMask Desktop support would be important too as I suspect that’s what most DAO members use.
The application works fine on Windows and Linux installation. We have tested it on a VM with Ubuntu installed as well. To create an Electron App we need to do it on a Mac, but we can try to do it with a VM next week.
But I see in your screenshot that you are connected on localhost with your wallet, you need to connect to the Ethereum mainnet or the Rinkeby network. We are using the React Js version of the dApp and it works on these two networks. For Metamask we need to find way out how to integrate it, the methods that we found are not working at 100%.
Ahh yes that was it. I had left my MetaMask Mobile connected to Arbitrum for something else I was playing with. When I switched it to Ethereum Main everything worked. Nice!
It’s a little confusing that it shows localhost when I was on Arbitrum but I’m not sure there is anything you can do about that.
I guess the next step would be adding support for more wallets like MetaMask Desktop. Or is there a way to use MetaMask Desktop through WalletConnect?
We need to investigate more alternatives to integrate Metamask desktop to Electron. For some reason this does not work with the methods already used, but we will check that again. It probably has to do with how the React app is created, otherwise we can add another package to the app like this: www.rainbowkit.com.
Integrating an existing App to Electron requires that you have certain requirements, when these are not present because of how it was created you have to figure out how to do it.
I doubt many people actually verify the build before they use the DAO but the fact that it can be done does provide an increased level of security that the build hasn’t been compromised.
Is there any way for a user to verify the Electron builds come from the unmodified source code in Github (which can be reviewed) and that it wasn’t compromised by the person who built the packages? (in this case, you)
I’m not sure if it’s possible but it would be interesting to find out.
Well, when you create an application in Electron all the files are saved in an .asar file which concatenates them into a single file. In this situation it is not possible to perform the procedure you recommend, plus we use the version of React js and not Docker for which this methodology is made.
It only remains to raise some possible options:
Make available a repository with all the pre-electron conversion files. But in this case it would only be the react files that would have to be verified.
Create a github action so that by means of a pipline the files are updated directly from the original repository.
Deliver to Api3 the adapted project and they will be in charge of creating the Electron App.
In any case, in the end it is the Dao’s decision to make available a “potentially compromised” application.
I don’t understand this option. What are “pre-electron conversion files”? Why would only the react files have to be verified?
Is it possible to do this and automatically build packages for Windows and OSX?
I’m not sure that solves anything. It begs the question of what is the API3 DAO? Are you not also part of it? Having another DAO member do the builds has similar risk.
I’ll think about these options a bit more and follow up. If anyone has ideas on how a user can verify that what’s in the downloaded installer is a true build of the unmodified source from the git repo please share!
We are using the react js version, we are not using Docker for this App. The guide to verifify the hash needs to create a docker-compose.yml file and install IPFS. So it is not clear to me that this process will work with a packaged Electron App either.
The second option is technically possible, but will require time and testing.
I meant that the core technical team or the team that created the original App should be in charge of auditing the code prior to creating the Electron application.
Anyway, any suggestions are welcome, and we will be reviewing some more options.
I see. I didn’t mean to imply that the steps to verify the docker build on IPFS would also work for this. I just meant we would need to find a way to accomplish the same thing with Electron builds - verify that the code in the build artifact hasn’t been tampered with.
