Define technical requirements to support web2-only user
ryanchristo opened this issue · comments
Summary
In conjunction with regen-network/regen-server#375, we need to identify technical requirements to support a web2-only user (a user without a connected wallet) within the marketplace application.
Questions
- What are the requirements for a web2-only user experience within the marketplace application?
- What pages and views are dependent on a wallet address? Of those pages and views, is the dependency necessary?
- What architectural improvements could we make to better support users with or without a connected wallet?
For Admin Use
- Not duplicate issue
- Appropriate labels and zenhub epics applied
- Appropriate contributors tagged
This could also be rephrased as the impact regen-network/regen-server#375 would have on the marketplace application.
Hey team! Please add your planning poker estimate with Zenhub @blushi @flagrede @ryanchristo @wgwz
This will also depend on whether we still use session cookies or go with a JWT/access token approach.
- What are the requirements for a web2-only user experience within the marketplace application?
- What pages and views are dependent on a wallet address? Of those pages and views, is the dependency necessary?
This part is more a design task than a technical requirement but it should infer the technical requirements so this is a good place to start I guess, to make sure we all align on the following.
Web2-only users have originally logged in using passwordless authentication with a verification code/OTPW sent via email or via any of the social providers listed just below. In the latter case, the user email address would be pre-filled with the one we can get from the social provider.
Web2-only users can only perform off chain actions:
- edit their profile
- edit their settings:
update email v2- connect social accounts: google
- connect Keplr/WC wallet address or create address through web3auth (only Keplr/WC for v1)
- create off chain (open) projects without any credit class
See design: https://www.figma.com/file/Sb9BavGvlCFPQFpjdDlwsL/Web-2.0-log-in-and-actions?type=design&node-id=245-13495&mode=design&t=6D1qIoJdhbgoOevT-0
They can't see any on chain data on their profile.
As soon as a web2-only user clicks a button that requires on chain transaction signing, the user should first see what a logged out user would see. For instance, clicking on the "buy ecocredits" button on a project card would display the current buying options modal:
But as soon as the user clicks "buy credits", we currently display a keplr login popup on top of it:
This should probably be updated to be "connect" instead as on https://www.figma.com/file/Sb9BavGvlCFPQFpjdDlwsL/Web-2.0-log-in-and-actions?type=design&node-id=628-131989&mode=design&t=6D1qIoJdhbgoOevT-0 and would prompt the user to prove the address ownership from Keplr so it gets linked to the user's current account.
On this regard, we also need to think about what should be the UX when a web2-only user becomes a web3 user, ie as soon as a wallet address is connected to the existing email-based account, in particular when managing the projects the user created. If the user's address is a credit class issuer, should we add the ability to set the credit class for existing projects and create them on-chain?
Web2-only users have originally logged in using passwordless authentication with email.
If we are going to allow for adding social log in on the settings page, should we also allow for it as the initial method for creating a web 2.0 account? In this case we could pre-fill the email field on the settings page with their social email and allow them to additionally log in via passwordless log in using that email address.
- update email? cc/ @erikalogie
I think we should leave this for a later version
On this regard, we also need to think about what should be the UX when a web2-only user becomes a web3 user, ie as soon as a wallet address is connected to the existing email-based account, in particular when managing the projects the user created. If the user's address is a credit class issuer, should we add the ability to set the credit class for existing projects and create them on-chain?
Yes we could allow them to do this. I guess in this case when they click the "edit" button it would take them through the web 3.0 create form with the option to select a credit class as well as fill in the metadata form and then create the project on chain.
closing in favor of the actual implementation of the front-end changes #2171