Deposits App

[yeqbfgxjiq]

The deposit forwarder allows Aragon organizations to require users place a deposit before forwarding an intent. The deposit amount and time locked are configurable by the organization. The user can reclaim their deposit after the time lock expires. This going to work as "middleware" app that filter intents that fulfill conditions. The forwarder has an interface (like voting), but rather than requiring a vote it just requires a deposit be locked up for some time.

• Status: not under development

@0xGabi

• I agree on this as well. Sounds really interesting.

@lkngtn

• I imagine you generally support this since you added it to the original HackMD doc?

@burrrata

• This sounds a lot like PoS Conditional Hashcash and that it might make sense to extend it with the option to burn the deposit/stake if the proposal is spam, but if not the person submitting a proposal gets their stake back. This would be very useful as decentralized spam reduction is something top of mind for the CFDAO and could benefit the broader Aragon/DAO ecosystem.
• /u/carlslarson (on Reddit) is building a similar thing for Daonuts (which is also an Aragon project) and suggested that this could also be turned into a challenge-response game where all submissions are approved by default, but if you flag something as spam and the broader community agrees with you there could be a small reward. If we want to move forward with this I think it makes sense to ask /u/carslarson if he wants to collaborate.
• Also, since we're exploring the design space of spam mitigation in social settings @vbuterin mentioned a few good ones here that are somewhat similar to what we're exploring, particularly the scorched earth anti-spam idea.

[lkngtn]

This going to work as "middleware" app that filter intents that fulfill conditions. The forwarder has an interface (like voting), but rather than requiring a vote it just requires a deposit be locked up for some time.

For everyones benefit, useful to read through https://hack.aragon.org/docs/forwarding-intro

extend it with the option to burn the deposit/stake if the proposal is spam

Agreed that it could be interesting to explore a few extensions, but I think trying to make it conditional might be a bit more complicated then we want. How would you determine if it is spam?

I do think having the option for the deposit to be sent to a vault, burned, or returned after a delay would not add too much complexity but would provide slightly more optionality in terms of how it was used.

/u/carlslarson (on Reddit) is building a similar thing for Daonuts (which is also an Aragon project) and suggested that this could also be turned into a challenge-response game where all submissions are approved by default, but if you flag something as spam and the broader community agrees with you there could be a small reward. If we want to move forward with this I think it makes sense to ask /u/carslarson if he wants to collaborate.

Cool!

I saw https://www.reddit.com/r/ethtrader/comments/bom330/decentralising_donuts_project_update/ on reddit today, it looks like he has been doing some really cool stuff. If he is building something similar it would definitely be cool to collaborate.

I'm also quite curious if his modified token manager and voting apps are generalizable/useful for other things.

Also, since we're exploring the design space of spam mitigation in social settings @vbuterin mentioned a few good ones here that are somewhat similar to what we're exploring, particularly the scorched earth anti-spam idea.

Will have to dig into this a bit more, it also sounds relevant to the court research.

[yeqbfgxjiq]

Open Questions For All BEEs 🐝

• Is this something we would want to work on?
• Do we agree that these apps are simple and straightforward to develop?
• What is the expected scope and a reasonable timeline given our resources and other commitments?

[yeqbfgxjiq]

@lkngtn read through the forwarding docs. Would the Deposits App be a type of forwarder (all in one), or an app that creates a condition where the forwarder can only be connected to if a deposit is submitted (modular as described below)?

• Deposits App: if deposit => proceed
• Current forwarder flow we use in the 1Hive DAO: forward vote request to voting app
• New flow: place deposit and instructions in Deposits App => if deposit > threshold => forward vote request to voting app

Regarding /u/carlslarson and DAOnuts: he's built lots of various mechanisms and apps over the last few months or so. Since he's already using Aragon as the base platform, and is developing apps, it would be awesome to turn those into something that the entire Aragon ecosystem could use. That being said, he's really focused on Daonuts right now and probably wouldn't want to do 1Hive specific stuff. For a collaboration to be effective it would have to be on an app Daonuts and 1Hive can both use as is. He's really smart though, and is building things that the /r/ethtrader community is actually using, and Aragon needs more examples of DAOs, so I'd really like to see the work he's doing being supported and more broadly accessible.

[willjgriff]

@burrrata regarding the new flow, it's very similar to the old one, any function that requires a deposit to be executed would grant the permission to the deposit forwarder app to execute it, a user would have to place a deposit in the deposits app using the deposits app UI, and when it comes to executing the function it would tell the user they will be executing it through the deposits forwarder (as opposed to another forwarder like the Voting app or TokenManager app).

• Is this something we would want to work on?

This seems fairly useful to the wider Aragon community. It sounds worth building.

• Do we agree that these apps are simple and straightforward to develop?

The only unknown with this app for me is how we might inform the user why an intent is failing eg because they haven't put a deposit in the deposits forwarder app. Alternatively how to prompt the user to make a deposit when they make the intent if they need too, although this is probably out of scope for now. I think both of the above would require looking into how the aragon client works and potentially making changes to it.

• What is the expected scope and a reasonable timeline given our resources and other commitments?

With my experience working on Aragon apps independently of a team I estimate about 2 weeks for one developer, without the extra prompt or error message at intent creation, for a basic functional version.

[lkngtn]

Alternatively how to prompt the user to make a deposit when they make the intent if they need too, although this is probably out of scope for now.

This is how I imagine it working, it seems far more complicated from a UX perspective to make a deposit separately then go and try and perform the action, and there is also not a link between the action being performed and the deposit (so a spam filter mechanism this might be more complex).

I think that the transaction pathing logic may actually have this built into the client already, so not sure we would need to make any changes to the client itself. For example when you try and perform an action that requires a vote, you are prompted to create the vote and when you confirm the transaction it is actually calling the create vote transaction and passing the "intent" of the original action through. In the case of the deposits app, it would prompt them to deposit funds, and pass the intent to perform the action on to the next node in the transaction path (possibly a vote, possibly a final action). I think we can look at how this is implemented in the voting and token manager apps.

[lkngtn]

Closing this as the requirements have now been documented in the readme #2, and there is a seperate issue for estimation #3