🛠 PR Checks Summary

AllAutomated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Codecov Report

Attention: Patch coverage is46.74556% with90 lines in your changes missing coverage. Please review.

📢 Thoughts on this report?Let us know!

I didn't follow up on this 🤦‍♂️

I think the general idea of this PR is good, but the execution needs to be changed a bit.

I'm not sure if we should require a GitHub app for verification. Is there a workaround for this?
We essentially just need the GH username, no other access.

We would add a button on the modal UI for this specific network that says "Connect GitHub" or something similar, and the middleware should check if the user's account matches some criteria (we'll define it, no worries). cc@alexiscolin

I didn't follow up on this 🤦‍♂️

I think the general idea of this PR is good, but the execution needs to be changed a bit.

I'm not sure if we should require a GitHub app for verification. Is there a workaround for this? We essentially just need the GH username, no other access.

We would add a button on the modal UI for this specific network that says "Connect GitHub" or something similar, and the middleware should check if the user's account matches some criteria (we'll define it, no worries). cc@alexiscolin

Hello thanks for taking a look :)

I think there is not a way ensure user is owner of that account without having a Github Oauth app but I'll take a look. (If problem is the difficulty, whole process takes like 30 seconds).
or maybe the idea was to just have a username input without ensuring user is owner ?

or maybe the idea was to just have a username input without ensuring user is owner ?

Yes, we have to make sure user the gh owner, username is not sufficient.
Otherwise, faucet farming will be too simple.

or maybe the idea was to just have a username input without ensuring user is owner ?

Yes, we have to make sure user the gh owner, username is not sufficient. Otherwise, faucet farming will be too simple.

@zxxma@Villaquiranm

Got it, so there is no way to avoid the GH app.
Can we make it open sourced on the gnoverse org?

The permissions it requires should be suuuuuuuper minimal

@alexiscolin How do you think the flow should look like on the Faucet Hub modal?
I assume there is gonna be a button "Verify with GitHub", if the user has not authenticated before, and when they do, some kind of text confirmation in the modal?

@alexiscolin for reference,https://gnolove.world/ has GitHub & Adena integration

Hello@zivkovicmilos
Sorry for the delay,

For github Oauth we have 2 elements client_id and client_secret.

Can we make it open sourced on the gnoverse org

If I understand correctly you want to have only one set of client_id/client secret among all faucets ? the problem I see with this is that we would need to share the secret to all new and old faucets.

The flow I was thinking about is for each faucet to create his own github Application so they will have their own secret. The client_id is safe to share (like the recapcha key) so we would be able to share on faucet hub likethis:

The permissions it requires should be suuuuuuuper minimal

About this point: if we do not pass any scope (on the faucet hub), by default we only obtain access to public information the flow can work with this level of permissions.

I took a look at the current, proposed, and ideal flows, and here is my suggestion:

1. On the faucet UI, you request the drip. (The link should be marked as external, so users understand they will be redirected to GitHub.)
2. You are redirected to GitHub to accept the request.
3. You are then automatically redirected back to the faucet UI, returning to the pending state. (A refactor is needed here, as I don't think this is currently possible.)
4. After returning and receiving the transfer notification, the pending state should be updated with either a success or error message, displayed in the modal as it is today.

For the cooldown:
2. Current flow: pending → error message (a new error message should be added for cooldown cases).

What do you think?

Quick question: What happens to users who don’t have a GitHub account? Should we consider using two different drip buttons based on whether the user is logged into GitHub (in this case the GH one would disappear)? I ask since I know a lot of people don't have GH account and will need the faucet to work.

cc@zivkovicmilos@zxxma@Villaquiranm

I took a look at the current, proposed, and ideal flows, and here is my suggestion:

1. On the faucet UI, you request the drip. (The link should be marked as external, so users understand they will be redirected to GitHub.)
2. You are redirected to GitHub to accept the request.
3. You are then automatically redirected back to the faucet UI, returning to the pending state. (A refactor is needed here, as I don't think this is currently possible.)
4. After returning and receiving the transfer notification, the pending state should be updated with either a success or error message, displayed in the modal as it is today.

For the cooldown: 2. Current flow: pending → error message (a new error message should be added for cooldown cases).

What do you think?

Quick question: What happens to users who don’t have a GitHub account? Should we consider using two different drip buttons based on whether the user is logged into GitHub (in this case the GH one would disappear)? I ask since I know a lot of people don't have GH account and will need the faucet to work.

cc@zivkovicmilos@zxxma@Villaquiranm

@alexiscolin

We need the GH login for very specific networks. Others will use the captcha like they do now