The goal is to provide a user with a single tool to manage all his or her DAO-activity. In first instance this project will focus on Aragon-type DAOs, later to be expanded by any type of DAO, all wrapped in one enjoyable and effective user-experience. API side of the proposal, that provides notifications as webhooks, links nice with Aragon Wallet RFP.
The first iteration was done during ETH Berlin last August, we iterated quite a lot on backend infra (reorgs!), UI design side of things, as well as marketing side - spoken to quite a number of DAO orgs while validating the idea, calculated some data.
Also very cool is that you already have users. Congratulations!
A few questions:
Currently it looks like the way a user “signs in” to the DAO Dashboard is by connecting the app to their Ethereum address. If so, what if a user creates unique addresses for every DAO they participate in? Would this data be stored in the users profile on your servers, or as a cookie in the user’s browser, or something else entirely?
In the user interface section is says: “A user is able to view all key-metrics for each DAO, as well as vote on active proposals (if he has permission to do so according to DAO-structure).” Does this assume that all DAOs follow a standard architecture? How would you support Aragon DAOs with different types of apps and events? Given the modular nature of Aragon DAOs, the complexity of this is likely to increase over time.
It was mentioned that you might be able to integrate webhooks to make chat bots and things possible. Also, very into the idea of being able to easily spin up DAOs for meetups or onboarding forms. This seems like it would provide the most value to a broader audience, so really interested in better understanding your thinking here. How would this work?
One concern per post. Sign In We provide ability to enter multiple addresses in addition to the main one, provided by web3, to cover ultimate one-address-per-dao case. These are stored in 3Box profile, linked to the main address. Currently, the interface for managing the list looks like this:
The addresses are not marked as belonging to different providers (like, Fortmatic or MetaMask), or even if they belong to the user. This poses a problem when supporting in-app actions, like voting. Also, this requires a user to sign in with the “main” address.
On Step 3 - In-app Voting the plan is to mark these accounts with appropriate providers. In this case, the user “signs in” with main address, but still has ability to confirm her actions with an account of choice. It goes with linking multiple “main” accounts into the same 3Box account, so that you could use different main accounts on mobile and on desktop, yet have the same list of watched addresses.
This is true, it would increase over time. key-metrics are mentioned for purpose. We see a certain distribution on what applications are installed, so the goal is to cover few most used and/or most asked and/or most valuable with high fidelity. The ones of Democracy, OpenEnterprise, Fundraising are the good start. For other cases, it is still voting that follows a certain meat-space pattern, so generic functional stub would work ok. So, we start with apps and scenarios of ours and our friends/partners on defining what are the most used votes (token distribution, funds transfer, app installation, agent (!)), and go from there.
In order to handle reorgs we have to use events, that could be committed or reverted with the block. Currently, the indexer handles organisation-created, app-installed, and token-transfer events. As per proposal, we will extend that to votes and voting events. Handling webhooks for us means one more destination for the event, that fans out HTTP calls. From user’s standpoint, web hooks part means selecting events (like token-transfer within specific org) the user is interested in on UI side, and accepting them on, well, web hook handler side.
Technicality further. The scenario starts with a GraphQL mutation to create subscription. It creates a subscription entry linked to a web3 account. On raw event (possibly simulated, to test a call), a fanout function would be called, that emits a call event per subscription. This one is passed on a caller function that really calls the webhook.
This is a really cool idea, but as stated in the Nest repo we are only accepting applications for RFPs at the moment. Will keep this project in our thoughts as it’s clearly awesome, but I wouldn’t expect it to move through the Nest program anytime soon. That being said, always happy to discuss the idea in general here if you have any questions or updates.
@burrrata if Nest isn’t funding anything other than RFPs, why did you request further information on this proposal?
Your initial response to this proposal was very positive (“Hey this is really cool ”), but only served to give false hope that it would get funded.
Furthermore, prompting @ukstv to waste more of his/her valuable time to answer your questions was unfair given that you knew the proposal would not be accepted.
With recent controversy involving funding of e.g. Prysmatic Labs, you may wish to think long and hard about how you engage with independent developers, otherwise you risk damaging Aragon Association’s reputation yet further.
Also, for the avoidance of doubt, the Nest repo does not state that it is “only accepting applications for RFPs at the moment”.
Can I suggest that the Aragon Association works to clarify exactly the process for applying for Nest these days, to avoid other projects wasting their time.
Also, the “Apply for Nest” link at the bottom gives me a 404 right now
The Nest GitHub README says: “If you would like to submit an application that is not related to an RFP, please start a discussion on the Aragon Community Forum in the Nest category. We will engage with you to determine if the idea is a good fit for Nest, and if so, we will create an RFP for it.”
@ukstv created a thread to discuss an idea. That’s all that’s happening here: a discussion around an idea.
Perhaps it would be less ambiguous and less prone to misinterpretation if the Nest GitHub Repo README said:
“we are only accepting applications for RFPs at the moment.”
Perhaps link to the RFPs that are being commissioned right now. When things change, you can update it with a simple PR.
The Ethereum Community is working hard, and we can’t afford to waste time on grant proposals which are not going to be accepted, or to share ideas without appropriate funding or compensation in place.
Aragon as a project, an association and a community is building a reputation for itself as one which freely takes intellectual property under the pretence of “open source discussions”, “grant applications” and “fighting for freedom”, and gives little to nothing in return.
The participants are turning into the very agents of centralised control parodied so overtly in your marketing collateral…
