🪣 Migrating Magic to Privy

zakhap commented 4 weeks ago

Description

We want to migrate our web3-SSO system from Magic to Privy to improve our wallet experience and sign-in options. This migration will allow us to support smart contract wallets, embedded wallets, and various sign-in methods (EOAs, SSOs, Farcaster) more effectively.

Motivation

Improve user experience with better sign-in flows
Support multiple sign-in options (EOAs, SSOs, Farcaster)
Stay competitive in the evolving crypto landscape

NonGoals (Jake added)

Sign in UI and UX will not change, beyond any components provided by magic.

Project Owner

@zakhap

~PRD~ Product Research Doc

https://www.notion.so/buildcommon/Migrating-to-Privy-afdfa915a6134d529d1f0a90995567e6?d=e45362d33ac8432fa0097f9e7f65b899#934f60edebf2423da56c5fce5e4fd522

Tasks

Set up Privy Integration
- Create Privy account and obtain API keys
- Integrate Privy SDK into our application
- Configure Privy settings to match our requirements
Implement User Migration
- Develop script to use Privy's "Import Users" endpoint
- Test migration with a small batch of users
- Plan and execute full user base migration
Update Authentication Flow
- Modify sign-in process to use Privy. This will include WalletConnect/Metamask as well as SSO. [Jake added]
- Implement new wallet connection options, specifically Farcaster and Telegram and SMS. [Dillon added]
- Update UI to reflect new sign-in options (deprecate magic)
Handle Existing Magic Wallets
- Assess number of Magic-generated addresses with assets
- For ETH addresses, migrate all content owned by addresses to newly generated Privy address.
- For Cosmos addresses, deprecate
Implement Pre-generated Embedded Wallets
- Setup generating wallets for new users
- Client should be able to sign messages using Privy embedded wallet, all content creation/updates should get signed by wallet.
Update Cosmos Wallet Handling
- Maintain flow for signing in with Cosmos Wallets, Cosmos communities should only be able to sign in with Wallets now.
Update Solana Wallet Integration
- Modify Phantom Wallet integration to work with Privy (Privy handles, use Privy to handle)
Testing and Quality Assurance

Design Links

N/A

Design Screenshots

N/A

Additional Context

No response

jnaviask commented 3 weeks ago

@raykyri will this impact session key support at all?

jnaviask commented 3 weeks ago

@ianrowan to investigate work items involved, then we will pair up with Platform team to execute on changes necessary. Will write subtickets as output.

raykyri commented 3 weeks ago

No impact on session keys assuming Privy always assigns a wallet to each user.

FC may not give you a fully featured wallet address, so that might take an extra API request to Privy to provision the address for Farcaster users. I assume Common wants to have an attributable pub key for each user always for contest/monetary purposes though, so using it for session keys wouldn’t be extra work.

ianrowan commented 3 weeks ago

Outputs of research so far to share before creating sub-tickets

Task 2: Privy suggests to use their just in time user migration pattern, although we can still use their user import. For just in time we would keep our existing user model, but extend for a privyDID field. Upon existing users first use privy will return an isNewUser field which will indicate if the user is new. From there we can save the new DID at the user level lazily. This is just information, if we otherwise want to migrate our entire user model to privy proactively we can call their REST API endpoint with a LinkedAccounts object for each user(ie addresses, email, socials) and receive a privy DID to add to their User model in return. I believe we need to use the proactive route for magic users 100% but for others it would only be necessary if we want to proactively(vs just in time) create multi-address associations. Both processes are straightforward so please advise which direction to ticket?

Task 3: Authentication is simple as its handled by privy for SSO. Once users exit the privy auth process web3 providers become available from the usePrivy hook which can be used to complete required signatures in our existing flow. This is also true for contract transactions. The evm based WebWalletsshould ultimately be consolidated into a single privyWebWallet for maximum compatibility, though this might not be the most efficient implementation of wallets any more given privy is hook based and web3 provider doesnt need the same 'initializations' as usual. (ie privy hook can be used instantaneously in components where web3 invocations are going to occur and doesnt need to be part of app state(trying my best with react/PENG terminology here)) Do we want to move in a direction to scrap webWallets?

Task 4: We currently have 19633 evm magic addresses. It would be assumed that ~100% of these are empty wallets though a script will be required if we need to confirm, in any case even if we delete the addresses the private keys are still accessible on magics side for users permanently, so true asset loss isn't possible outside of magic having an issue. The best way to migrate these imo would be to use the user import REST endpoint on privy with email/social as the LinkedAccount data for each account with createEthereumWallet=true in the request. This will create a privy account for all emails/socials and return privyDID's and addresses which we can replace the magic addresses with. ++Do we have any comms with privy on this/is there a standard/suggested method?

Task 5: Easy to create embedded wallets and access via usePrivy hook. signature methods available directly from provider object which will use embedded accounts.

Upon decisions on Task 2 and confirmation/comment on task 3/4 comments will begin ticketing PENG/Platform tickets

CC @jnaviask

jnaviask commented 3 weeks ago

@ianrowan what are the pros and cons of the lazy/just-in-time vs proactive approach for task 2? Tasks 3 and 4 make sense -- we should definitely move away from webWallets if possible. That said, a question I have is how we will continue to support Cosmos logins without privy, how the two can coexist architecturally?

ianrowan commented 3 weeks ago

@jnaviask

The pros to lazy are

Accurate representation of users/effort to onboard them
set up/use existing privy account as a new user
avoid errors/missed users in proactive that will need to be reconciled via the lazy patter any way Cons
Biggest con is multi-address/address + social etc would need to be manually linked by users(ie if they sign in with two different addresses privy will treat both as new users vs 1 if we proactively provide all linked account)

Pros to proactive

Create frictionless setup privy accounts for users before first signin
retain linked address/social/emails, etc Cons
Platform effort to script and create new model of privy DIDs accurately
May be a stretch, but some users may consider this to be data sharing(ie their linked addressed from our db to privy)

For the cosmos login point I think we could leave cosmos login untouched and just create two conditional paths to capture a signature upon sign-in for privy vs cosmos. ie the privy flow resolves to a react hook we can call anywhere(ie inline with sign-in logic), cosmos continues to use webWallet. I would assume PENG will have a way to discern if the users click through the privy flow or cosmos and this assumes we give the option at the beginning of the sign in process from a product perspective

jnaviask commented 3 weeks ago

@zakhap any thoughts on which direction is preferred from a product standpoint?

zakhap commented 3 weeks ago

replying to @ianrowan + @jnaviask

I believe we need to use the proactive route for magic users 100% but for others it would only be necessary if we want to proactively(vs just in time) create multi-address associations. Both processes are straightforward so please advise which direction to ticket?

From my research, I also believe we should be proactive for all of our Magic users so the accounts don't get orphaned. I don't believe it should matter whether or not we JIT migrate the other users, HOWEVER, if we're already migrating one subset, why not migrate them all so we don't have to account for JIT migration? That way, there are two subsets of users, those who have been migrated and New Users (getting rid of the JIT user subset). The Cons to Lazy outweigh the data sharing with Privy concern.

Do we want to move in a direction to scrap webWallets?

I think we should be going this direction. Reducing overhead in top-of-funnel is key consistency+reliability here. Cosmos will just have to be maintained as a separate flow.

ianrowan commented 3 weeks ago

One additional point to mention as I was just walking through some privy demos is that I believe a product decision to be accounted for will be the additional signature privy will add if we are to still use the session key signature siwe step.

For context, when connecting to privy with a wallet they prompt a SIWE message to be signed which is what they use to validated wallet ownership. In our current flow the user would have to sign this, then sign a similar message for our sign-in. Privy can provide us assurances the user signed and is signed in so I think our current model wouldnt be using privy for user management to the full extent given we would still need to handle a full sign-in flow in the app. Privy itself is built to be a user/session management solution, so just using them to access web3 providers/SSO vs an eventual migration to use their full feature set may be sub-optimal

CC @zakhap @jnaviask

raykyri commented 3 weeks ago

Do we want to move in a direction to scrap webWallets?

This raises some concerns for me, let's please discuss this offline.

hicommonwealth / commonwealth