Access Levels Based on Address, Github, Email

[FlacoJones]

NO CONNECTION

• View Contracts

GITHUB

• CRUD user profile

GITHUB + Wallet Connected

• CRUD user profile
• Fund, Refund, Create, AND CLAIM

GITHUB + Wallet Connected + On-Chain Wallet Connection

• CRUD user profile
• Fund, Refund, Claim and Create
• Get paid out automatically in hackathons

EMAIL

• CRUD user profile
• Receive update emails

EMAIL + Wallet Connected

• CRUD user profile
• Fund, Refund, and Create
• Receive update emails

Sign Up Flow

• New user, "Login" button on top right. No Wallet Connect showing.

• NOTE: (If they try for Fund, Refund, or Mint Contract - say "Login" - then show Connect Wallet)

• Click Login button, show modal with Github or Email login

• Main sign up modal - should be exciting, explain the benefits, etc.

• Check email is unique etc.

• Redirect them to their fresh new user profile, encourage them to fill it out

• After redirect (whether it's from MagicLink redirect or OAuth redirect), if it's a new user redirect to user profile, prompt to add username

[ArcAnya]

Why did we want to force Github sign-in for create, fund, refund again? I think it's not too complicated to allow this without github login..? Was it to be more united on the sign in logic side? (I'd want to refactor the code a bit so that we always use the same component ConnectButton for connecting the wallet where needed, then it's easier to implement the logic isAuthenticated or not in case we want to adapt this logic)

Also - should we add the logic for stuff to be invoiceable? I guess that would be EMAIL + Wallet Connected + Minimum Info for Invoices? (both on the funder and claimer side?)

[rickkdev]

Two options:

a) we dont make it a requirement, only if invoicing is required (because then we need you to sign up and add your invoicing data)
b) we make it a requirement to track users, we want to see how many we have, if we miss out here its bad for two reasons:

• we dont know how many real users we have
• we cant send those people potential updates via email that reminds them of a cool app they used but just forgot about

Vote for a with rocket and for b with heart

[ArcAnya]

Kind of torn on this one. I believe that for Fund, Refund, Create (i.e. pure funder actions) it would be potentially better to allow it with only one step, i.e. connecting the wallet. I think the wallet addresses (plus the repo/org they fund issues for) would still give a good indication of the number of real users as funders. Making them sign in to Github as a prerequisite (which is what we were going for I think?) also does not guarantee that we have their email address (and if we want we could get those from the github org people from funded issues via graphql).

[Christopher-Stevers]

I think it would be good to have them sign in with github before doing these actions, because we 1) don't have to worry about managing account only users (you could call them ghost users) and 2) it would make the UX of login similar because it would be remove the confusing aspects of being possibly logged in with github and possibly connected with an eth account.

[FlacoJones]

So if Andrew signs up for a hackathon, we have an email user with UUID 123.

Andrew then later OAuths with Github. We now have a Github user with UUID 456.

We don't yet know I'm the same person.

Where and when do we link the two?

On the https://app.openq.dev/user/123 page for my email user, it will say Link your Github

On the https://app.openq.dev/user/456 page for my email user, it will say "Link your Email"

Once I link my email to my Github, we merge all my Email info INTO the Github User. We then delete the old email user. It is now still a unique email in our API as it HAS TO BE.

On the other hand, once I link my Email to my Github, nothing happens besides A) checking that the email is unique, and B) inserting it into my existing Github user.

When Email and Github users collide, Github absorbs the email user.

[FlacoJones]

One problem is that this would break old links to the https://app.openq.dev/user/123 page since that user would be deleted.

Unless perhaps we use usernames?

[rickkdev]

couldnt we create an automated redirect to the merged account?

[FlacoJones]

Yes but just gets messy. Redirects need to be stored somewhere.

[Christopher-Stevers]

Any update on this? As we integrate the new API we are going to need to handle this with the frontend.

[FlacoJones]

Should we AUTO-LINK the Github if I OAuth while signed in as an email user?

Should we AUTO-LINK the Email if I Email auth while signed in as a github user?

[rickkdev]

An important aspect is that there is no email user from my understanding to which you can log in to. It's just stored in your cookies (and our DB) if you sign up for hackathons on your phone so you don't have to fill out the same form over and over, and we can later reference your information with a real registered user account.

So for case 1) yes. For case 2) there is no email auth.

[Christopher-Stevers]

An important aspect is that there is no email user from my understanding to which you can log in to.
@FlacoJones is this really the case? Since the email user is in the user collection it seems like their is really a user authenticated with email.

[Christopher-Stevers]

How are we going to connect ethereum address connected data in the subgraph to our users? Do we just use the on chain address to external userid connection?