Next Steps

[Keyrxng]

Requires #1

• NextJS integrated
• Full WebAuthn flow (leveraging @simplewebauthn)
• Secure credential creation and authentication handled server-side
• Demo UI (mostly aesthetic)
• Faucet funding integrated
• Signer never exposed to the client
• Cookie-based auth sessions

---

My design skills leave you wanting but the UI isn't the main focus here early on. I was just beefing it up to make the demo look a bit more presentable.

My intention is to implement permits generated for the new EOA to claim with the faucet funds which will round off V1 if the stopping point is implementing 3rd party AA solutions like Safe.

---

Still working towards the goal of no OAuth for the claim portal, just passkey, but I haven't put any work into the portal besides having it render.

Once I have the full logic down E2E I'll focus on refining logic, finding bugs and improving security.

---

Still a WIP but it should be E2E testable for anyone via the deployment url. It works both locally and remotely for me so I expect no real issues.

• There's a CSS callback issue happening that seems to resolve by clicking the UI

• When in /account the account management tabs may take a little bit to load and may require a manual refresh but once rendered it doesn't happen again even after refresh

• The faucet worker seems to hit CPU limits after each successful request and then becomes inactive for some period of time afterwards. The worker I have deployed is a refactored memory optimized version of the current development branch which improved things slightly but I'm not sure how improve this further (advice I've taken is from stackEx etc)

Testable here: Removed because my OAuth is now pointing to localhost

Screen.Recording.2024-07-11.001733.mp4

[github-actions]

Unused dependencies (31)

Filename

dependencies

package.json

@octokit/request-error @octokit/rest @radix-ui/react-accordion @radix-ui/react-alert-dialog @radix-ui/react-avatar @radix-ui/react-dialog @radix-ui/react-dropdown-menu @radix-ui/react-popover @radix-ui/react-select @radix-ui/react-slot @radix-ui/react-tabs @radix-ui/react-toggle @radix-ui/react-toggle-group @radix-ui/react-tooltip @safe-global/api-kit @safe-global/protocol-kit @safe-global/safe-core-sdk-types @simplewebauthn/browser @simplewebauthn/server @simplewebauthn/typescript-types @ubiquity-dao/rpc-handler @vercel/kv class-variance-authority clsx cmdk dotenv lucide-react next-themes sonner tailwind-merge webauthn-p256

Unused devDependencies (5)

Filename	devDependencies
package.json	@commitlint/config-conventional @ubiquibot/permit-generation esbuild postcss-nesting tsx

Unresolved imports (1)

Filename	unresolved
tests/main.test.ts	../static/main

[Keyrxng]

@0x4007 This is where I'm at with things over the last couple days. First comment covers things I just forgot to tag

While I've been using TailwindCSS inline off the cuff, I know it doesn't make for very maintainable code. Once the logic is firmer and a real vision for the UI exists that will be the first thought when refactoring the demo UI.

[0x4007]

Its really cool to see that I can log in with iCloud keychain. I think this is ideal, and I can access the same account from all my devices.

I couldn't understand how to actually use the wallet at all though. Any way I can see the wallet address? I don't understand when or how the faucet operations work, but would be interesting to see on chain.

[Keyrxng]

I think this is ideal, and I can access the same account from all my devices.

This makes us heavily reliant on OAuth as right now everything is bound to a user through auth attached to a session but the pros outweigh the cons.

I'm going to remove credential entropy usage and find some elsewhere that way the EOA/Safe is attached to the account which is accessed with passkeys.

I couldn't understand how to actually use the wallet at all though. Any way I can see the wallet address?

It's mostly a logic empty UI right now. I expect to have it all ready over the weekend and will have improved

I don't understand when or how the faucet operations work

Right now it's manual via the UI and only a few wei is being sent, I need more gas and to top it up. The faucet accepts an address param and funds the address. I have no checks or guards on it right now but basically we'd create the EOA store it in the database and either fund it immediately or do it pre-permit.

would be interesting to see on chain.

https://amoy.polygonscan.com/address/0xcdd8145c082fb1c08874eda94f671cf6725553eb

[0x4007]

Found my address! Cool to see

[Keyrxng]

I've got server side transactions like transfers and minting test tokens but was having issues with sending permitTransferFrom txs. I think my issue is with not knowing ethers v6 too well so I'll migrate things over to viem and see if I have better luck with it

[0x4007]

ethers v6

In the past I've used not the latest version of ethers because of ChatGPT code generation not knowing the latest. I think its a valid strategy to do if its easier/faster to ship.

[rndquu]

Perhaps instead of using faucet as a worker at safe.ubq.fi it makes sense to move this logic into a separate bot's plugin.

This way the flow for an end user would 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.

In the next iteration (if we decide to implement safe gasless transactions) we could simply remove faucet plugin from the organization config and let safe.ubq.fi generate a new Safe account via Safe's SDK.

[rndquu]

Perhaps instead of using faucet as a worker at safe.ubq.fi it makes sense to move this logic into a separate bot's plugin.

This way the flow for an end user would 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.

In the next iteration (if we decide to implement safe gasless transactions) we could simply remove faucet plugin from the organization config and let safe.ubq.fi generate a new Safe account via Safe's SDK.

@Keyrxng There is a new issue for a crypto faucet plugin at ubiquity-os/plugins-wishlist#35.

Regarding this PR we should:

1. Remove worker code
2. Make sure user's wallet address is saved in a DB on passkey generation

Correct?

[Keyrxng]

Correct mate yeah! I had placed this on hold sort of while I (we) focused on pushing V2 urgent or high priority issues but yeah

So a user would register at this UI, we'd create their wallet etc and then the faucet plugin funds their account on issue.closed so long as they haven't been subsidized before.

The faucet can be streamlined so much as a plugin and would be better not being based off of our faucet imo, i.e no need for oz defender etc anymore.

[rndquu]

The faucet can be streamlined so much as a plugin and would be better not being based off of our faucet imo, i.e no need for oz defender etc anymore.

You mean that since we have access to a partner's private key we can simply fund accounts from that address?

It makes sense to keep a separate address for the faucet in order not to mix funds between rewards and faucet payouts.