Building modules

[adamgall]

Been thinking a lot about how to structure and format the idea that "modules" will likely be upgraded over time, and how to best signal those upgrades to DAOs which have "installed" those modules.

The ideal UX would likely involve the webapp "recognizing" that a module author has released a new (compatible) upgrade to their module, and prompt a DAO to perform an upgrade.

How to do that?

@christopherdancy @tbwebb22 ideas? I have a couple of ideas, but would love to hear from you first.

[christopherdancy]

Hey @adamgall,
Each module emits an event when an upgrade has occurred. Each module instance also has an implementation which it is tied two. We can use the implementation contract as the signaling tool and keep record of any DAO which uses said implementation.

[christopherdancy]

Here is my current process to setting up the gov mod.

1. Utilize OpenZ Governor
2. Replace upgradability permissions w/ Access Control
3. Timelock controller compatible
4. Override Timelock controller's execute function to point to DAO's transaction
5. Provide Timelock controller the execute role in Access Control

[christopherdancy]

Taylor and I thought through the idea of hot-switching voting modules and we do not like the idea that voting weight will change during a proposal.

Therefore, we think it is best that voting modules are fixed to governor modules. If someone would like to change this, They can connect another governor module or upgrade the current governor module.

[adamgall]

For the sake of a thought exercise, let's imagine a future in which an entrepreneurial developer has created their own Fractal module.

1. The developer "deploys" the first version of the module to the blockchain.

• What exactly is "deployed" to the blockchain?
• How many new addresses exist on-chain as a result of a brand new module being deployed for the very first time (but not yet "used" by any DAO)?
• What kind of code exists at those addresses? (meaning, is it generic "proxy" code, an implementation template that will be used to create implementation instances, a single implementation instance that will be shared, etc)

This module implements some logic that people just freakin love. It gains traction on Crypto Twitter and GitHub.

2. A few dozen DAOs "install" it into their DAO.

• What exactly is "installed" to a DAO?
• Put another way, what address(es) is (are) added to the DAO's AccessControl contract?
• Is it an instance of a non-upgradable contract?
• Is it a proxy contract?
• Is it some kind of other contract?
• Is the address unique for this DAO, or is it an address that all few dozen DAOs are sharing?

Now let's say that this developer likes the traction that their module has gained, and wants to do a lil rent-seeking. They write some more code into their module's codebase which adds more functionality, but also introduces some fees for using the original functionality.

3. Developer deploys an upgrade to their module.

• What does this "deploys an upgrade" process look like?
• Does the very act of this developer "deploying an upgrade" change the behavior of the original module that the few dozen DAOs installed? (hope not)
• How do the DAOs become aware that the developer of their beloved module has deployed an upgrade?

Members of the DAOs do their due diligence. Some DAOs weigh the tradeoffs of this new logic + fees, and decide that they want to upgrade. Other DAOs are like "nah".

4. A subset of the DAOs using the module decide to opt-in to this upgraded module

• What happens when a DAO decides that want to upgrade?
• What happens if a DAO decides that they are perfectly content with the original logic, and don't want the new behavior (and fees)?

This is enough for now. But these are the things I'm thinking about and I want us all to be on the same page about how we're designing this.

[adamgall]

https://reactjs.org/docs/code-splitting.html

This looks promising, for the functionality of letting module developers build their own frontends that the Fractal webapp can dynamically load

[adamgall]

@christopherdancy does any of the above resonate with you?

i spoke with @tbwebb22 about my thoughts and intentions behind the scenario i documented above.

if you haven't yet, please sync up with him :) i want us all to give input and understand what the bigger architecture patterns should be, before diving too deeply into "finishing" any given module implementation.

[christopherdancy]

@adamgall This makes tons of sense. I like the way you are thinking. This should become more of playground of builders rather than a static DAO deployer. We should start thinking about creating bounties for modules. This will begin to build this ethos.

In regards to our current tech... I think any pattern is currently supported. Composability is at the base of what we are building.