We’ve been talking about agent app at Aragon One, and Jorge has been working on smart contracts for it. The idea is that it can interact with other smart contracts on your DAOs behalf.
Right now the app is a smart contract only without any UI, so I created a user interface for it.
The first idea was to reuse the Finance app UI for this. I thought it would also be nice to have the external dapps/smart contracts persist, so I’ve used cards for them.
The idea is that you click “New external contract”, give it a name (and optional avatar url), enter the smart contract address, and we load the ABI and create a card.
Then you can click the card to interface with the contract as the DAO - choose the function and parameters you want to run (these are automatically populated for you in the dropdowns) and execute the action as a DAO. Since you are executing it as a DAO, depending on how the permissions for your DAO are set up it, can first require a vote etc.
This is quite similar to https://oneclickdapps.com where you get a UI for any smart contract by just entering the address (or copy/pasting the ABI).
I like this as it seems like it would be an intuitive way to manage a whitelist of external functions, which could then be assigned different internal permissions.
However, I want to throw out the idea that this should not necessarily be considered the Agent App front-end, but rather that we should think of this as something distinct that adds functionality to the Agent app, similar to how we think of the vault in relationship to the finance app. The finance app provided a UI for making transfers to and from a vault and implements some basic budgeting functionality. Similarly the app you have mocked up provides an interface for whitelisting specific external functions (and perhaps creating roles/permissions associated with them), but it could logically be separated and installed independently from the agent app.
Small thing but rather than loading the contract avatar from a URL could it instead be an IPFS hash?
There are a few ens domains that resolve to an ipfs address of a static website. portalnetwork.eth is one of them. I think it might be cool at some point to have a web3 only browser which can only connect through web3 protocols. This might be the place for that.
has there been any other work on a front end for the agent app?
Or will it be an app without a frontend?
I think the work by @jouni would be very useful like @lkngtn said to enable granular permissions from an intuitive interface. It is definitely sub-optimal to have to do this from the CLI!
Who is currently working on the agent?
We will likely be working on this as part of the scope for 0.8. However, help is always welcome
The more we use Agent, then more it becomes clear, there is no need for Agent UI. What actually would be a killing feature is being able to use DeFi Dapp UI’s with Frame signing each transaction and creating a Vote if needed. That would open much more possibilities and interoperability, leaving UI on the side of each Dapp. Integrating Frame into Zerion for example would create a nice dashboard where eligible user could create an interaction.
Absolutely, and that’s why Frame 0.2 is experimenting with Agent integration. You can try it by building Frame yourself off of master: https://github.com/floating/frame (unfortunately no downloadable build is available yet but soontm).
I think it would be useful to have at the very least a “read-only” Agent UI installed in an organization that shows a history of transactions created using Frame, and their current status (pending, rejected, confirmed, etc). But I agree that for actually using Agent with other smart contracts, a native signer integration such as Frame is probably the best, most efficient way to use it.
I would prefer Agent to not have even a read-only UI direcly. (Though I know that has already been included in 0.8 )… I think it would have made more sense to update the finance app to include arbitrary transactions or provide a agent-frontend app that could be installed along with agent if needed. I would support creating a fork of agent called agent-lite that brings back this minimalism…
The reason for preferring agent without a frontend is that some use cases of Agent will be narrow and tied to interaction with specific services (eg livepeer delegation, or ens management) and it may not make sense to have a full account history show up as a separate option in the menu. It may also be the case that you want to connect finance to an agent app, and now you have two menu items to effectively accomplish the same thing.
Yes, transactions with Agent is a very useful feature. However we started using Zerion and perfectly fine with it