Closed ianrowan closed 2 weeks ago
@ianrowan for the unscoped wallet page, let's do something basically that is -> https://www.figma.com/file/KOEVNGXStBhmX3NnYq7MxP/Community-Stake?type=design&node-id=1812-63466&mode=design&t=w1GVYke1zIrqcxrE-4
similar to this
and across the top add a + button (opens in app modal to paste the WC items)
cc: @egetekiner for item number 4
Upon build out relaying on backend(or potentially frontend) to relay the signature to the smart account associated with the user.
While full arch for transaction relaying not really in scope, seems impt to ensure that Platform / Eng Leads are looped in at least lightly.
I think the full event storm etc should happen after we have the POC within our app
cc: @egetekiner for item number 4
Upon build out relaying on backend(or potentially frontend) to relay the signature to the smart account associated with the user.
While full arch for transaction relaying not really in scope, seems impt to ensure that Platform / Eng Leads are looped in at least lightly.
I think the full event storm etc should happen after we have the POC within our app
@dillchen For this one I'm almost pretty certain station will relay for us via an API call, just need to confirm. That's at least what I got from the value prop of their API/paymaster abilities etc
@ianrowan makes sense, sorry I meant transaction Queuing / storage. I.e "I have received a tx back from some app, but I have not signed with my MM"
Step 1. (Allow user to create a group OS smart account)
will be covered by hypermeme wallet lite spec #7190
@ianrowan would it be possible to to stub the other remaining bullet points, seems like other remaining functionality is the following
- Metamask/wallet adapter functions to request signature of transaction object per ERC4337/groupOs validation standard(TODO, add docs here)
- Backend Route or frontend logic to push signed transaction to smart account(via chain or groupOS api). Either way user should only sign and we relay via our own pkey backend or push to groupOs on frontend
Looks completed based on #8044
Creation of an unscoped set of /wallet routes/pages that
Allow user to create a group OS smart account Allow users to paste a wc connection link from another Dapp Allow user to sign incoming requests creation of model to store relevant smart account information per user address
@dillchen Created https://github.com/hicommonwealth/commonwealth/issues/8049 for the UI work left. Then there is also #7191
Just to be accurate #8044 creates a backend route that allows for creation and db storage/fetching of a users smart account.
The scope of #7191 and #8044 also have nothing to do with walletConnect to be clear for the demo purposes. These were roadmap specific tickets for tg bot and other relaying services using smart accounts. So the end result of a POC here would be:
So this is essentially everything above except for wallet connect(esp b/c w/o group OS WC is less straighforward) or at least isnt scoped for that b/c the purpose was for relaying, etc
All makes sense to me — Will ensure that this context is relayed to rest of team
Sent via Superhuman @.***>
On Tue, Jun 04, 2024 at 3:47 PM, Ian Rowan @.***> wrote:
@dillchen https://github.com/dillchen Created #8049 https://github.com/hicommonwealth/commonwealth/issues/8049 for the UI work left. Then there is also #7191 https://github.com/hicommonwealth/commonwealth/issues/7191
Just to be accurate #8044 https://github.com/hicommonwealth/commonwealth/pull/8044 creates a backend route that allows for creation and db storage/fetching of a users smart account.
The scope of #7191 https://github.com/hicommonwealth/commonwealth/issues/7191 and #8044 https://github.com/hicommonwealth/commonwealth/pull/8044 also have nothing to do with walletConnect to be clear for the demo purposes. These were roadmap specific tickets for tg bot and other relaying services using smart accounts. So the end result of a POC here would be:
- User can create a smart account with us and them as signer
- We can prompt user with a tx(ie send eth to x from smart account) and they can send it with one click(no sig)
- Opens up for relaying via multi-auth patterns = POC our sessions/jwt provides auth, we push tx for user. Extends to tg and other services we need to relay from
So this is essentially everything above except for wallet connect or at least isnt scoped for that b/c the purpose was for relaying, etc
— Reply to this email directly, view it on GitHub https://github.com/hicommonwealth/commonwealth/issues/6864#issuecomment-2148299882, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIWMHOVCKN5J7LJVDYYXMTZFYKUJAVCNFSM6AAAAABDW3NE6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGI4TSOBYGI . You are receiving this because you were mentioned.Message ID: @.***>
Redundant.
Description
We've been working with station to get our ERC4337 infra set up. They created packages under the name
groupOS
. The tl;dr is that we want to enable a flow similar to the demo they've provided for integrating their wallet connect hooks. The specifics of what this require is:@groupos/walletconnect
- this is also the package that will be used for creating the wallet connect hook.Project Owner
@ianrowan
Engineering Requirements
/wallet
routes/pages thatAcceptance Criteria
Additional context
For context the typical wallet connect flow here(focusing only on desktop UX/non-QR code) from the user perspective is:
my wallet
page(or w/e) - waiting for a Wallet connect linkmy wallet
page - upon successful connection wallet page moves to receive transaction view