Crypto faucet

[rndquu]

We have plans for generating contributors' ethereum wallet private keys via webauthn passkeys in order to make reward claiming "gasless". So the flow for a contributor could be:

1. User calls a /register command (handled by the faucet plugin). The bot replies with smth like "Pls register your account at safe.ubq.fi".
2. User opens safe.ubq.fi, generates a new passkey, we derive user's private key and public address, user's newly generated wallet address is saved to a DB.
3. When user solves an issue (i.e. the issue is closed as completed) the faucet plugin sends some funds to the user's address.

There already exists a faucet worker at https://github.com/ubiquity/faucet. We need to wrap https://github.com/ubiquity/faucet into the bot's plugin.

So as a part of this issue the faucet plugin should:

1. Handle the register (or similar) command in order to show to a contributor the "Pls register your account at safe.ubq.fi" message
2. Handle the issue's "closed as completed" event and send some funds to the contributor's wallet (if that's the 1st issue solved by the contributor and he hadn't received funds earlier)

Original comment.

[Keyrxng]

@rndquu I can start and have this finished today if you think I should put a rush on it

I'm thinking that we should also build it so it's reusable for other partners too and not just for our specific use-case

---

sorry for the tag, I was thinking out loud and was a silly remark I was about to make

User calls a /register command (handled by the faucet plugin). The bot replies with smth like "Pls register your account at safe.ubq.fi".

So we have

• /wallet and that's our registration command, so would /register aim to deprecate that plugin all together and would be replaced by this? So everything /wallet does this plugin should also do (if applicable)
• startRequiresWallet check in /command-start-stop, which would just stay the same or would this be updated with the comment go register at...

[rndquu]

I can start and have this finished today if you think I should put a rush on it

So we can put a time estimate of 1 day here? I don't think we should put a rush on it. @0x4007 rfc

I'm thinking that we should also build it so it's reusable for other partners too and not just for our specific use-case

Yes

/wallet and that's our registration command, so would /register aim to deprecate that plugin all together and would be replaced by this? So everything /wallet does this plugin should also do (if applicable)

I don't think /wallet should be deprecated. That's just another plugin for another registration flow. The /wallet plugin saves address to a DB while the faucet plugin (on /register or similar command) should simply display the "Pls register your account at safe.ubq.fi".

startRequiresWallet check in /command-start-stop, which would just stay the same or would this be updated with the comment go register at...

ubiquity-os-marketplace/command-start-stop#22

[Keyrxng]

Is ubiquity going to be the primary source that a user registers at? So in terms of a partner opting to install this, they'd need to follow the same AA approach that we do right?

I have made additions such as ERC20 distribution etc but it would require that the partner use this plugin as their registration command too.

I have attempted to implement the decentralized storage solution and so it means that it's user base would be nil and they'd need to go to the portal to register but then that would store it in the ubiquity repo and not the partners.

So will ubiquity's start-stop-command and this plugin need to track something like Record<String, Record<String, UserData>> => storage["partnerName"]["username"] = {}?

[0x4007]

No all data storage should be in every partner's ubiquibot-config repo in plain json storage.

[Keyrxng]

Okay this is my understanding of things correct me if I'm wrong

• partners install /start so they can have their users start their tasks.
• These tasks will be included in our devpool-directory repo as issues.
• Our bot will reward their users from their funding wallet.
• These users will need to have called /wallet inside the partner's repo and it will store the user wallet in the partner's json storage.

in this scenario, no AA so it's straightforward to register.

---

• partners install /register. User calls command and we make an empty entry in the partner's json storage as at this point we know the partner from the payload.
• /register posts a comment saying go to safe.ubq.fi to finalize registering which is where the EOA is actually created
• We cannot ID the partner and so we cannot fetch or write to their storage.

---

So in my mind the correct flow should actually be this:

• /register
• Go to safe.ubq.fi and generate EOA
• go back to issue and use /wallet pasting the previously generated EOA

It potentially adds friction or inconvenience to the user but we simply cannot achieve partner-based storage with an AA flow without potential errors. i.e I do not think it is safe to use a query param when we comment go to safe.ubq.fi

[0x4007]

i.e I do not think it is safe to use a query param when we comment go to safe.ubq.fi

Why not?

---

So we can put a time estimate of 1 day here? I don't think we should put a rush on it. @0x4007 rfc

It's no problem. If Keyrxng is motivated to handle this right now then they are free to put a rush to it

I'd rather have high contributor engagement across multiple initiatives vs low contributor engagement on a single focused task. Everything needs to get done eventually and we don't have any short term deadlines at the moment.

[Keyrxng]

i.e I do not think it is safe to use a query param when we comment go to safe.ubq.fi

Why not?

Well there is no restrictions to registering with a partner but all registrations are clearly visible with a comment on an issue that cannot be missed. We know we just got a new user.

With a query param, a user could register for any partner without notice. Idk how much of an issue this actually is but it doesn't seem right. We could ensure an empty entry with their username actually exists in that org first? But if this is not an issue then I guess a query param might be okay for this purpose

Which raises the scenario:

• user A registers with partner X
• they get an EOA created with their webauthn details
• user A wants to contribute to partner Y who also uses this flow
• now they must register another account (EOA)

We do not have cross-partner account checks. We do not keep a centralized record of registered accounts.

The portal however could notice that a passkey exists (unless on a different device) but we'd have no way to attribute that passkey (account) with a particular org. So I think so long as we enforce a Github login and entropy is not partner-related we should be able to generate the same EOA and store it across partners. I'm confident.

---

In all cases the frontend will need to fetch from the partners private repo, how do we have access to that without using the bot token?

Also is it secure to fetch, parse and save new data from their private repo? We naturally have access to their actual config with sensitive data. If handled server-side I assume so but this probably needs investigated right?

alternatively, we generate the account only and require that the user return and use the /wallet command which mitigates the above two issues

---

I'd rather have high contributor engagement across multiple initiatives vs low contributor engagement on a single focused task. Everything needs to get done eventually and we don't have any short term deadlines at the moment.

Good to know.

Keyrxng is motivated

Yes. Jk but I do feel in-the-zone with plugins at the moment so I'm letting the wind carry me

[rndquu]

alternatively, we generate the account only and require that the user return and use the /wallet command which mitigates the above two issues

So in my mind the correct flow should actually be this:

1. /register
2. Go to safe.ubq.fi and generate EOA
3. go back to issue and use /wallet pasting the previously generated EOA

Sounds good, it's simple enough for v1 "gasless payouts" (although adds 1 more registration step for a user). Handling multiple partners, their own json storages and backend for safe.ubq.fi can be omitted for the next feature iteration.

Besides json storage SDK is not ready yet.

[rndquu]

alternatively, we generate the account only and require that the user return and use the /wallet command which mitigates the above two issues

So in my mind the correct flow should actually be this:

1. /register
2. Go to safe.ubq.fi and generate EOA
3. go back to issue and use /wallet pasting the previously generated EOA

Sounds good, it's simple enough for v1 "gasless payouts" (although adds 1 more registration step for a user). Handling multiple partners, their own json storages and backend for safe.ubq.fi can be omitted for the next feature iteration.

Besides json storage SDK is not ready yet.

If @0x4007 accepts this flow for v1 "gasless payouts" (i.e. our minimal version of account abstraction) then I'll close ubiquity-os-marketplace/command-start-stop#22 as "not planned".

[0x4007]

@rndquu seems fine

I just wish that our UI could directly write to the database instead of the user needing to register their wallet after. The less steps the user needs to take the better the user experience.

We will need to notify on our UI that their wallet has been updated to 0x....

[rndquu]

@rndquu seems fine

I just wish that our UI could directly write to the database instead of the user needing to register their wallet after. The less steps the user needs to take the better the user experience.

We will need to notify on our UI that their wallet has been updated to 0x....

ubiquity/safe.ubq.fi#3

I think we can start simple and leave the "save wallet address to a DB at safe.ubq.fi" feature for safe.ubq.fi v2.