faucet.gno.land - a faucet hub for the Gno ecosystem

[zivkovicmilos]

Description

This is an idea that has been in the back of my mind for some time now, and I thought I'd discuss it on the hackerspace repo, as it might be a fun project for the team to do.

Basically, the idea is to build a faucet hub (hosted at faucet.gno.land) which would provide a clean UI interface for all the faucets in the Gno ecosystem (gno.land, staging.gno.land, different implementation partner testnets...).

Functionality:

• Enable the user to select which network faucet they want to receive funds on (with a limit)
• Provide field/form to enter the address manually
• Show the balances of each different faucet (for each network)

Nice-to-have:

• Support 3rd-party networks via PR (JSON structure: endpoint, image, etc.)
• Show the user's balance (selected address) for the different networks (somehow in the UI)
• Provide an option to connect an Adena wallet (and use the address from it) (not necessary; keeping for history)

In the future, this can be expanded for funds other than native currency (ugnot).

The faucets are hosted on separate machines independently, so the UI would just be hitting the APIs of the faucet implementations (gnolang/faucet).

If development teams want to add their faucet to the app, they can just open up a PR and have it appear and working when merged.

Additionally, a Discord bot can be set up that will provide the functionality offered by the UI, but in message / command form over Discord.

Looking for thoughts
@waymobetta @leohhhn @dongwon8247 @alexiscolin @AidarItkulov

[waymobetta]

Initial meeting to discuss priorities: 1/18/24

[dongwon8247]

@zivkovicmilos Thank you for creating this issue.

Provide an option to connect an Adena wallet (and use the address from it) (not necessary; keeping for history)

I agree this would not be necessary. But alternatively, would it be possible for us to natively integrate this faucet function in Adena? like the image below.

"Please send me some testnet tokens" is one of the most asked questions by the community (Esp in #adena channel in Discord) when they enter the Gno ecosystem first. So we tried to implement this feature via Discord with Ray and Manfred (link) before, but it got pending for some reason.

This feature can be helpful for new users and dApp developers to get some tokens easily and try out the latest testnet (+custom testnets). The only issue we previously had was setting up the faucet rules to prevent draining by scripts, so we planned to add things like a Captcha, lowering quantity per request, a limit per account per day etc.

If possible, I'd like to integrate this on Adena!

Related: gnolang/gno#364, gnoverse/community-faucet-bot#1

[waymobetta]

I always wondered why wallets didn't integrate faucets or bridge interfaces directly within them, makes a lot of sense to me. MM is just now doing this.

[waymobetta]

Faucet-hub related repo.

[zivkovicmilos]

Please send me some testnet tokens

I need this on a t-shirt 😄

The faucet hub will only be a gateway for using different faucets, and not having to worry about specific testnet request handling (we leave this up to the faucet server). Adena can do the same -- I propose we converge on a common standard for detailing a faucet (what makes up a faucet object, like name, URL, max limit...). This way, Adena could possibly feed our community faucet info (from the repo) into the UI, and act as a gateway (similar to what the faucet hub page will be).

What do you think @dongwon8247, @waymobetta ?

[dongwon8247]

Sounds good to me. Let me know if you need input on this task!

[thehowl]

Would a better idea not be to phrase this as a "Gno Testnet hub", rather than a "faucet hub"? So you have a list/UI of testnet, AND information on how to get test tokens there.

👍 for the idea, though :)

[zivkovicmilos]

@dongwon8247 @alexiscolin @kristovatlas

I've mulled over the request structure the UI would need to be sending to the faucets, and it requires minimal changes to our existing gnolang/faucet implementation:

interface Request {
    To: string;     // recipient address
    Amount: string; // <AMOUNT>ugnot <--- new
    Captcha: string // captcha response from the UI <--- new (optional)
}

The "specification" for each faucet is straightforward, and needs to be simple so the UI is not bloated:

interface Faucet {
    Name: string;       // name of the testnet
    Amounts: number[];  // faucet serve amounts (UI)
    URL: string;        // the faucet URL
    ReCaptcha: string;  // the recaptcha site key, if any
}

In order for us to support custom network security protocols, it would be an insane feat on the UI side to manage, and a security nightmare to handle.

Each network faucet can have an initial security step: the captcha. For v2 we can look into OAuth, meaning people can sign in with Discord, GitHub, Google…

The base captcha is good enough for v1, because:

• every faucet is going to be behind a firewall anyways
• every individual faucet can have their own security middleware regardless of the UI (and the Faucet Hub)
• it doesn't make @alexiscolin's life a nightmare with unmerged features and untested functionality gets us to a v1 much, much quicker

All testnet faucets need this basic security step of authenticating a request, and if the network doesn’t want it, they disable it by setting ReCaptcha to empty, meaning the UI won't issue a captcha challenge. This would also integrate smoothly with the Adena mocks provided by @dongwon8247. It’s minimal overhead on the UI, because each captcha box is actually the same, and each request standard (follows the above structure).

I'll push out support for the custom amounts on the gnolang/faucet repository, and after that merge in the standard for the faucet hub repo

EDIT: added support for custom faucet drip amounts here

[kristovatlas]

@zivkovicmilos This sounds good to me.

Do you think any of the participating faucets would want to implement their own additional security measures, such as a reCAPTCHA they control or another CAPTCHA product? It's not immediately clear to me how we could make that work on a faucet hub without at least introducing additional parameters. I'm hoping the answer is "no" and we can just keep it clean.

We will need to establish a shared secret or authenticated communication channel with the faucets so that they can authenticate a request to send funds came from our hub and not an attacker impersonating the hub.

[kristovatlas]

@zivkovicmilos Thank you for creating this issue.

Provide an option to connect an Adena wallet (and use the address from it) (not necessary; keeping for history)

I agree this would not be necessary. But alternatively, would it be possible for us to natively integrate this faucet function in Adena? like the image below.

"Please send me some testnet tokens" is one of the most asked questions by the community (Esp in [#adena channel in Discord](https://discord.gg/qYmDmmga)) when they enter the Gno ecosystem first. So we tried to implement this feature via Discord with Ray and Manfred ([link](https://github.com/gnoverse/community-faucet-bot/pull/1)) before, but it got pending for some reason.

This feature can be helpful for new users and dApp developers to get some tokens easily and try out the latest testnet (+custom testnets). The only issue we previously had was setting up the faucet rules to prevent draining by scripts, so we planned to add things like a Captcha, lowering quantity per request, a limit per account per day etc.

If possible, I'd like to integrate this on Adena!

Related: gnolang/gno#364, gnolang/community-faucet-bot#1

Just a warning about integrating this into a wallet -- you may not want to include Google's recaptcha JS code in your wallet in case this js code is ever compromised. Sandboxing using iframes or a framework like LavaMoat can mitigate this risk. If I were a black hat and ever compromised reCATPCHA's js, the first thing I would do is include a generic text box inviting users of any web UI this got included in to paste their recovery mnemonics.