Save EOA to a DB

[rndquu]

Depends on https://github.com/ubiquity/safe.ubq.fi/pull/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 https://github.com/ubiquibot/plugin-template/issues/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]

@Keyrxng Pls check the description and put a time estimate

[0x4007]

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]

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]

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]

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

[Keyrxng]

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]

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.

[thisisdavidlong]

/wallet 0x8b46200A13a7018125a4682462aa2d86Fa93ae6c

[ubiquity-os[bot]]

+ Successfully registered wallet address