Giveth / Roadmap

Open Roadmap Planning via Tokenlog
0 stars 1 forks source link

Multisig Compatibility with the dApp #67

Closed laurenluz closed 5 months ago

laurenluz commented 1 year ago

We should allow multisigs to interact with our dapp, donate, create projects, stake, use GIVpower!

laurenluz commented 1 year ago

Account abstraction is going to be huge in Ethereum! Gnosis safe is going to incentivize users to use a gnosis safe as their personal wallet.

divine-comedian commented 1 year ago

From what I can see most apps on gnosis-safe don't have a state of user-profile on their apps. This means the safe does not manage profile name or account information.

We should find a way to check if a connected address is a multisig right off the bat and depending so then the flow might have to be a little different. If I understand the main purpose of the initial login signature is to generate the JWT token. Is it possible to automatically generate it without specific consent if the address connected is a multisig?

What would be other complications from not specifically making the user sign in when they reach the site?

Ideally...

The user should not need to sign in to use the app right off the bat, instead we should require signatures at every step where the connected multisig would like to do any of the follow:

We'll also need to consider how to track these regular transactions:

We'll need a way for any of these interactions to be tracked and when the multisig process passes we actually execute the requested action, if it's fully on chain such as staking or locking GIV I don't think anything needs to be done. However for donating we need to be able to add the donation to our database and as well for boosting and updating profile info it's the same case.

In the absence of smart contracts or Giveth APIs we might want to think of using the safe-core-sdk tools to allow us to register a new multisig transactions as pending in our db and a manner of tracking it up until it passes or fails.

We could find a way of setting up the actions specified by a multisig owner and a cronJob to periodically check the status of a pending safe transaction. When it passes we execute the actions on our DB, if it fails we delete the proposed action. I don't think this idea scales well but for now it will serve us given our expected multisig volume and we can rework this when we have Giveth APIs

namely there are these packages here that might be able to help us: https://github.com/safe-global/safe-core-sdk/tree/main/packages/protocol-kit https://github.com/safe-global/safe-core-sdk/tree/main/packages/api-kit

divine-comedian commented 10 months ago

@CarlosQ96 FYI

Let me know if any of this makes sense.

divine-comedian commented 10 months ago

@MoeNick lets use this as the main issue for tracking

divine-comedian commented 10 months ago

random notes

Mateo did a flow with using web3 connectors - could make a donation with signing in mateo doesn't like web3 react because it isn't compatible with the most modern packages like wagmi and rainbow kit

back-end side is the same for any connector we need to go with, can make a quick version using the web3-react version

found an article about how to do it properly - just need to make a front-end decision, if its a multisig we call a separate authentication method otherwise regular flow. any call such as givpower, staking etc.. anything requiring a signature should work fine

once the token is ready for the multisig - we can make it so it doesn't expire so quickly, for an extra step

Can we create a batch so this only generates 1 tx?

What we should do

@aminlatifi says we can use EIP-1271 for signing the message from a multisig https://eips.ethereum.org/EIPS/eip-1271

Let's have the multisig log in from the front-end

When they attempt to sign-in we can default to a really long time (3 months) for their jwt token to remain valid and let them select from some shorter options if they only want to stay logged in for a specific smaller set of time.

This will allow the multisig to stay signed in for that set period of time and they only need to log in again (and thus sign a multisig tx) when the jwt token expires.

We should do this using the new wagmi and rainbow kit connectors

Mitch would also like to stress investigating how to batch txs so when a user wants to do an on-chain action such as donating, claiming rewards and staking GIV etc.. there is only 1 tx to sign

divine-comedian commented 10 months ago

Any blockers?

only blocker from the investigation was who should wait for the signatures for everyone to sign - it was some code that was listening to all the signs - the backend can't be waiting for it too long

the front-end can do it but we had to add an extra layer of security because the back-end must validate the front-end securely cause then everyone can make their own front-end and send things to our back-end. that was the only blocker. Hasn't found a solution yet,

is there anyone that can be helpful? devops not required, mostly investigation and see if anyone has done it before, not sure if anyone has done it using safe SDK

mostly front-end stuff to work through after that - front-end is expected to handle it and added a bit of security. needs to work on some other projects to free up time.

wagmi and changing wallet on front-end - safe has a specific connector in wagmi

can we review what other apps do for sign-in? I click on boost button, wait on signers to sign how should we handle it on mobile? the UX is a little bit confusing

when we need to sign something what happens on the user front-end what happens when other signers reject - what about other signers that visit our website during the confirmation of the sign in lots of edge cases that we need to understand.

@divine-comedian do some research on other platform

divine-comedian commented 10 months ago

Edges Cases we should consider

divine-comedian commented 9 months ago

There are first a login from metamask

second there is a message made on the multisig on the safe UI message is saved in the messages section of the transactions queue

need a custom modal when user clicks safe wallet icon from rainbow kit modal

show a modal that explains what is going on

when a user has a pending tx we need to tell them they need to pass it when they connect to Giveth - they sign the first tx from their personal wallet - prompt them to sign the multisig tx and give them the link to it

jwt token lasts 1 month - multisig session which is 1 week, if the multisig tx doesn't pass in 1 week they need to do it again if another signer comes in they only need to sign from their personal wallet

edge case first person who logs in after multisig tx gets token next person from signer - they will get a token after 1 week time-frame if they don't have a token

the token is issued from when the tx passes and user signs in the multisig session starts the moment the tx is made on the multisig

modify the session end date to match the duration of the first token issued

so user knows everything ends on a certain date

can we know if a signer makes a project or something can we emit a log of who did a certain action on the dapp?

giveth doesn't know which wallet is being used in gnosis safe when user has to sign in to get their jwt token - prompt the modal again?

can we prompt them with our own modal from rainbow kit with options from those wallet


2 step modal - click log in with safe from rainbowkit show modal with 2 steps

1 - sign in with your web wallet 2- generate multisig tx for your multisig signers to pass 3- tell them they can close the pop-up in multisig app, it can be found in messages tab 4- 5-

gn