Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save EOA to a DB #3

Open
rndquu opened this issue Aug 16, 2024 · 9 comments
Open

Save EOA to a DB #3

rndquu opened this issue Aug 16, 2024 · 9 comments

Comments

@rndquu
Copy link
Member

rndquu commented Aug 16, 2024

Depends on #2

Right now safe.ubq.fi is able to generate EOA address from a passkey but doesn't save it to a database.

This way user has to perform an additional registration step:

  1. User calls /register and the bot replies with "Pls create an EOA at safe.ubq.fi"
  2. User creates a new EOA at safe.ubq.fi
  3. User calls /wallet to register his address in our DB (additional step)

We should support the following flow:

  1. User calls /register and the bot replies with "Pls create an EOA at safe.ubq.fi"
  2. User creates a new EOA at safe.ubq.fi and safe.ubq.fi's backend saves user's address to a DB

Ideally for a DB we should use a partner's json storage (i.e. his ubiquibot-config repository) but if ubiquity-os/plugin-template#2 is not implemented at the time somebody starts this issue then we can simply use our supabase instance and leave "json storage" for the next feature iteration.

Original comment.

@rndquu
Copy link
Member Author

rndquu commented Aug 16, 2024

@Keyrxng Pls check the description and put a time estimate

@0x4007
Copy link
Member

0x4007 commented Aug 16, 2024

In order to decentralize but share data storage, perhaps we can have users set up their own .ubiquibot-config repository under their personal accounts, and we can read the data from there? Things like their wallet would be useful to save there.

For it to be private, the users must install the bot to their account.

The user can also host some plugin there, which opens up the "personal agent" proposal as a possibility.

Otherwise they can register wallets to each organization, which also might not really be a problem in the medium term.

@rndquu
Copy link
Member Author

rndquu commented Aug 16, 2024

In order to decentralize but share data storage, perhaps we can have users set up their own .ubiquibot-config repository under their personal accounts, and we can read the data from there? Things like their wallet would be useful to save there.

For it to be private, the users must install the bot to their account.

The user can also host some plugin there, which opens up the "personal agent" proposal as a possibility.

Otherwise they can register wallets to each organization, which also might not really be a problem in the medium term.

@Keyrxng

Overall it adds an extra burden for a contributor to generate a repo, install the bot, etc... We already "ask" partners to generate ubiquibot-config repo so it's more user friendly to simply store wallet addresses there.

@Keyrxng
Copy link
Member

Keyrxng commented Aug 16, 2024

I'd keep the /register => /wallet flow. They'd need to return to the issue and use /start anyway so I'd argue there's very little to no additional friction added anyway.

We could have each partner add the bot or another account and we use it's token or give us an access_token which we can use to read/write from our UI? access_token doesn't sound too attractive and and if we use the bot's I think that could be dangerous as it'll have access to all partners private configs.

Perhaps it would be a better idea to create a core plugin that we can dispatch events to from the UI passing the user details and the org they are registering for. Then (afaik) the kernel could read/write their org config no problem. It may have to be a service binding to the kernel as opposed to a plugin but this could work right?

@0x4007
Copy link
Member

0x4007 commented Aug 16, 2024

Can pass installation ID in the query parameter and auth with GitHub to associate the correct org securely.

@Keyrxng
Copy link
Member

Keyrxng commented Aug 16, 2024

Can pass installation ID in the query parameter and auth with GitHub to associate the correct org securely.

If I understand correctly, the problem with this is the Github app used for logging into the various portals is a different Github app then what's installed in each org Ubiquibot vs Ubiquity Rewards, as I'm sure is the case.

Unless we are storing these install IDs in our Supabase partners table we cannot use the portal app to authenticate the install ID if the above is true.

Or have a way to create the various tokens we need from the bot app to verify the install ID which might look like env vars?

@0x4007
Copy link
Member

0x4007 commented Aug 17, 2024

To generate the auth token we need the app ID, installation ID and app private key.

With those three we can auth to any org with the matching installation ID.

@gmkitty
Copy link

gmkitty commented Aug 27, 2024

/wallet 0x8b46200A13a7018125a4682462aa2d86Fa93ae6c

Copy link

ubiquity-os bot commented Aug 27, 2024

+ Successfully registered wallet address

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants