Aragon One product scope for 0.8

#1

Major Aragon releases always try to include big items that make the user experience qualitatively better.

This is my take on which features to prioritize.

Timeline: Mid-July

New onboarding

The current onboarding has some issues:

  • There are just two templates, and they are a bit confusing for users
  • Creating organizations requires two transactions

We should revamp the onboarding and its templates too.

Aggressive caching

Loading an organization created 6 months ago and with more than 100 votings takes several minutes. This hurts user experience.

We should look for ways to make the first load almost immediate, and then increase trust over time when the client is able to verify more and more of the organization’s state. We could look into tradeoffs between centralized/decentralized.

Push notifications

This becomes essential when organizations are holding important assets or funds. Even more so when the Aragon Court is out. We should look into ways of providing push notifications in the client.

UI for the Agent app

There should be a UI to check the log of actions that a given Agent app in an organization has done.
There should also be a way or creating transactions through the Agent, integrating that functionality into Frame.

Basic fundraising app

As it was planned and designed since the very first versions of Aragon.

This wouldn’t be an advanced app like Apiary, it would just be the most basic of all fundraising scheme.

Meta-transactions

So users wouldn’t have to hold ETH or pay for transactions inside a given organization.

Global kill-switch

Way to opt into an aragonOS global kill-switch that pauses contracts if a critical bug is found on them.

4 Likes

Agent app UI ideas
#2

Is this a Frame specific functionality or would users of other Ethereum providers e.g. MetaMask or Status Browser also be able to make Agent transactions?

0 Likes

#3

It’d totally work on them too, but it’d need custom integration on their end

0 Likes

#4

Is this something that would be appropriate for an EIP?

0 Likes

#5

Usually the coordination cost of going through an EIP is way higher than just building something that gains adoption and becomes a de facto standard.

1 Like

#6

Who has the authority over the kill-switch for aragonOS? Seems very dangerous and centralized to me, if controlled by a central operator.

0 Likes

#7

What coordination cost? You just define the standard and publish it in the EIP repo. The feedback process would be the exact same as if it were published in your own repo, and you get more visibility because it’s in a repo that a ton of devs look at for guidance on Ethereum-related standards.

0 Likes

#8

I mean the possible back and forth with many different stakeholders who may like changes to the original implementation for it to adhere to their needs.
Anyway this is something that I think Frame should do/should be done at the signing provider layer.

0 Likes

#9

My guess is that it would require a certain amount of ANT-weight to get activated. MKR has a similar process whereby if 5% of MKR-holders hit the kill switch the system goes into an emergency shut down. So that can mean one person holding 5%, of five people holding 1%. It’s not a perfect system because an attacker could theoretically borrow 5% of MKR, activate a shutdown and short MKR and make some profit. But, at the same time, a shutdown doesn’t necessarily mean a price drop since it is only temporary and it’s not easy to get your hands on 5% of a token’s total supply. You bring up a good point though, and I would be interested as well to hear what the plan is for Aragon’s implementation of this.

1 Like

#10

It will be great to see a fundraising app on Aragon again. I should point out though that it seems Apiary will actually support a “traditional” token sale structure, so you may want to sync with them and make sure this other fundraising app wouldn’t be made redundant by this.

0 Likes

#11

Good to know, I’ll certainly sync up with them. Even with that, there’s some front-end development that may need to get done, since we probably don’t wanna have a complex frontend (w/ bonding curves and stuff) for the simplest fundraising

0 Likes

#12

We are still designing the mechanism, @facuspagnuolo from our team (cannot find his handle right now, will update later) is the one doing that now. Hopefully it will be decentralized enough so not a single entity can trigger it.

1 Like