Modules into own repos (Client-Side)

[Da-Colon]

Each Module should be able to run in an 'iframe' popup without disrupting the UX on the app.

[Da-Colon]

For Pulling in data for 'iframe'. First part is where and how do we get this data.

We have discussed a module would just live in a github repo and URL on chain would point to the repo and displaying that in the front-end.

Could we in fact just have a DAO's module be hosted. Simple this only needs to be a simple app. this would allow a DAO to write in React or any compile language since it can be easily hosted either by github pages or netlify?

[Da-Colon]

So I'm sitting here thinking about the hows and whys of iframes and modules, Obviously we this is a little further down the road and this may be somewhat of a brain dump so apologies in advance.

What is a module, technically speaking?

• a set of contract(s)
• a front-end served (hosted)

What can a module do?

• it may need to execute transaction (needs signer)
• it may need to read contract data (provider)
• it needs to display a UI unique to the module
• it may need a onboarding workflow
• it should be installed multiple times
• it should live outside of Fractal framework
• we may require module to have pages on certain routes that can be linked to. (for onboading, or main module)

Current Implementations

I've seen a few examples that we can go with communicating with Iframes. but the take away is that the source must be verified by a trusted source. The solution I've seen so far usually end up being a web2 solution. (I'm sure there might be a web3 solution out there with more looking).

Thoughts

Function Execution (Signer)

So because the frontend already has some sort of ability to execute raw transactions. I think we should build this part up that what comes out of the iframe is an executable set of transactions that must be confirmed by user. with a specific dataset it mind we can set up validations and possibly setup some kinda encryption for more privacy (might not be needed)

Trusted Source

To prevent any problems with CORS. I saw we have a system that can we can use to do this. Plugins!. So I'm thinking that only DAOs would want custom Modules. and for a module to be installable it must be registered (by any) Fractal DAO in a proposal. This keeps both the decentralization and allow for us to have a list of 'verified' modules.

What would Register Module contracts look like?

@christopherdancy @tbwebb22

• verify url? (I'm guessing this is limited to format)
• verify it is a Fractal DAO address executing
• create/store URLs
• up/down voting (probably not needed)

I'm not sure of the current infrastructure so I may be off on the get go and we can use what currently built to 'register' modules.

Reading Data Provider

This is a little more tricky but maybe not impossible. We could require the first pass at this to just include their own 'read-only' provider. and we can validate that the network and chainId match? This would path would leave it up to the module to figure out how to 'get' the data and only needing the 'DAO address and/or account` to do whatever it needs to do

There is a library I have been playing with ethvalut/iframe-provider, but while I understand WHAT it's doing I haven't figured out the implementation in the parent app.

Still thinking this part through will have to test some solutions.
@adamgall

[Da-Colon]

Working parent -> iframe connection! (bottom is iframe. This is very much a prototype just passing working version and I need to clean this up but phew. using @ledgerhq/iframe-provider and our a branched version of our @decent-org/wallet-provider

[adamgall]

Not gonna lie, there's a lot of stuff in this post that I think I'm missing context for. I don't really understand the whole "trusted source" thing, as it relates to iframes, or why we need to "register"/"verify" modules.

I'm not sure if you're looking for any feedback from me, but if you are, it's probably best to start with a call so we can get on the same page.

Just let me know if/when that call should happen.

[Da-Colon]

Context is definitely missing. As far as a call on this subject I'm always down for feedback, but I don't want to distract from the current scope either as this is something that the front-end isn't ready to implement and we can push this conversation off for a bit.

To help with context in the mean-time.

Trusted Sources

So 'trusted' is used loosely here, but this what I propose. It first came from the thought of I would need to validate that this is indeed a link to a Fractal DAO compatible module. I think the idea was for installing the modules an address that we would be able to return information for that Module. This works but then when we open to a 'marketplace' or more user created modules we may want to have a way to store/retrieve information about modules kinda outside of a DAO. This I think where a 'registering contract' comes into play.

Registering Contracts

• A DAO can register a custom module to the market place through a proposal
• I say we still allow for 'any' compatible module to be installed, but registering allows for visibility and exposure for a DAO (we could link to the DAO that has registered it) as well as knowing that it is a compatible module.
• Since this is attached a DAO would give more credibility to a module.
• I guess this is first come first serve on 'registering', this would have to be thought out more.

As I write all this out more questions come to mind?

• What is a 'compatible' module mean?
• Could the marketplace set up in this fashion get overwhelmed? (tons of bad modules)
• might be a little weird to say any DAO can 'register' any module?

TL:DR I think this might be a whole different discussion that will happen after iframing if this route is decided on. Iframing well help with modularizing the codebase. but when we open the door to custom modules we would need to revisit these points