search

ubiquity-os / plugins-wishlist

0 stars 5 forks source link

KYC Permits #24

Open 0x4007 opened 4 months ago

0x4007 commented 4 months ago

Powerhouse inquired about KYC for payments.

Todo:

rndquu commented 4 months ago

Decide if we should intercept the /start command and check if they already KYC'd (seems like the best UX to warn them up front.)

The /start command should be responsible solely for using github API. We could simply put the "KYC plugin" in the config chain before the /start command and throw an error in case KYC is not passed.

0x4007 commented 4 months ago

We could simply put the "KYC plugin" in the config chain before the /start command and throw an error in case KYC is not passed.

Just because a plugin throws an error doesn't mean the others should halt execution, right? However, with this scenario it makes a lot of sense.

So we can associate a "sub plugin-chain" on the webhook event name level i.e. issues_comment.created and if any of those plugins fail in the subchain then halt the rest of that chain.

@whilefoo @gentlementlegen rfc

rndquu commented 4 months ago

We could simply put the "KYC plugin" in the config chain before the /start command and throw an error in case KYC is not passed.

Just because a plugin throws an error doesn't mean the others should halt execution, right? However, with this scenario it makes a lot of sense.

@whilefoo @gentlementlegen rfc

This looks like a plugin's SDK method similar to pluginSdk.halt()

hydroxylase commented 2 months ago

This is really interesting to me. Assuming we need a KYC check, what ID does the user need to provide in order to perform the check. By knowing this upfront, I can better think of a solution to this issue.

rndquu commented 2 months ago

Assuming we need a KYC check, what ID does the user need to provide

I suppose the exact ID type depends on a KYC provider. We can accept any as long as it is allowed to be used in the selected KYC provider.

hydroxylase commented 2 months ago

Assuming we need a KYC check, what ID does the user need to provide

I suppose the exact ID type depends on a KYC provider. We can accept any as long as it is allowed to be used in the selected KYC provider.

Thats okay. I get the idea. I'm proposing creatinga new command for the bot, '/kyc' maybe. In that way we could request the iuser to upload the ID or whatever it is that is required and have the KYC provider perform a check on it. If successful, the appropriate response will be returned

rndquu commented 2 months ago

Assuming we need a KYC check, what ID does the user need to provide

I suppose the exact ID type depends on a KYC provider. We can accept any as long as it is allowed to be used in the selected KYC provider.

Thats okay. I get the idea. I'm proposing creatinga new command for the bot, '/kyc' maybe. In that way we could request the iuser to upload the ID or whatever it is that is required and have the KYC provider perform a check on it. If successful, the appropriate response will be returned

We should start with "Research a suitable KYC provider" and check its API. Then we can get back to how exactly to use that API (bot command, UI page, etc...).

We shouldn't even store any legal documents on our side since everything should be handled by a KYC provider. The ubiquity organization only needs to call a method of KYC provider's API to check whether a particular contributor completed KYC or not.

0x4007 commented 2 months ago

We should start with "Research a suitable KYC provider" and check its API. Then we can get back to how exactly to use that API (bot command, UI page, etc...).

The findings should be discussed right here in the issue comments

hydroxylase commented 2 months ago

Okay

On Sun, 8 Sep 2024, 07:35 アレクサンダー.eth, @.***> wrote:

We should start with "Research a suitable KYC provider" and check its API. Then we can get back to how exactly to use that API (bot command, UI page, etc...).

The findings should be discussed right here in the issue comments

— Reply to this email directly, view it on GitHub https://github.com/ubiquibot/plugins-wishlist/issues/24#issuecomment-2336567292, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7M52GZS4G5IPVZI32XZNWTZVPV4PAVCNFSM6AAAAABJZI6CWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGU3DOMRZGI . You are receiving this because you commented.Message ID: @.***>

hydroxylase commented 2 months ago

Update. I was surfing the net for KYC/AML providers and stumbled upon swiftdil.com . Their documentation is pretty solid and straight forward maybe we can proceed to the second step of deciding where to perform the check.

0x4007 commented 2 months ago

Perhaps some search parameters we should consider are:

  1. No monthly fees - instead if we can do per KYC, then it is very simple to pass the costs off to our partner.
  2. Crypto is the focus - it seems that regulations and crypto are at odds with eachother.

Why did you settle on this provider over all the others? I would have expected a familiar brand name that the major exchanges use and such.

hydroxylase commented 2 months ago

I thought about it as well but there aren't much KYC providers out there that charge per screening.

Regardless, I acknowledge the need to refine the search. I recommended the previous provider mainly because of the documentation and presumably easy onboarding process.

I'll try to see to whether we can find another provider that matches your criteria

rndquu commented 1 month ago

https://www.sherlock.xyz/ uses https://web.fractal.id/

whilefoo commented 1 month ago

The ideal flow would be:

  1. User comments /start
  2. The plugin lets the user know that they have to complete KYC
  3. User comments /kyc
  4. The KYC plugin creates an entry in DB, initiates a KYC session and comments the URL that leads to provider's page
  5. When the KYC process is complete, the KYC provider sends a webhook to the plugin. The plugins marks the KYC as complete in the DB and posts a comment

Step 2

Two options:

  1. Assign the user but warn them that the KYC is required

Disadvantage/Problem: When the issue is closed, the permit is not generated if KYC is not completed, so the user can't get the reward even if they complete the KYC after Advantage: Less friction

The problem could be solved when we implement rollup rewards where we store the reward in the DB ledger but don't let the user claim on pay.ubq.fi until they complete the KYC

  1. Don't assign them and inform that KYC is required

Advantage: Less likely for the user to miss the warning and waste time completing the task (for example if they have privacy concerns) Disadvantage: More friction

Step 4

If the URL is posted to the issue, it means anyone can see it and potentially submit fake/troll documents to disrupt the service or post real documents and completes the process (but there's no incentive for that). As far as I know there is not way to send something on Github privately. We could send it over Telegram but I don't think we have implementation for that.

Step 5

Posting a comment when the KYC is completed would be nice but is not possible because the plugin doesn't have the Github token when it's called by the KYC provider

0x4007 commented 1 month ago

The ideal flow would be:

  1. User comments /start

  2. The plugin lets the user know that they have to complete KYC

  3. User comments /kyc

  4. The KYC plugin creates an entry in DB, initiates a KYC session and comments the URL that leads to provider's page

  5. When the KYC process is complete, the KYC provider sends a webhook to the plugin. The plugins marks the KYC as complete in the DB and posts a comment

Step 2

Two options:

  1. Assign the user but warn them that the KYC is required

Disadvantage/Problem: When the issue is closed, the permit is not generated if KYC is not completed, so the user can't get the reward even if they complete the KYC after

Advantage: Less friction

I like less friction approach.

The problem could be solved when we implement rollup rewards where we store the reward in the DB ledger but don't let the user claim on pay.ubq.fi until they complete the KYC

  1. Don't assign them and inform that KYC is required

Advantage: Less likely for the user to miss the warning and waste time completing the task (for example if they have privacy concerns)

Disadvantage: More friction

Step 4

If the URL is posted to the issue, it means anyone can see it and potentially submit fake/troll documents to disrupt the service or post real documents and completes the process (but there's no incentive for that).

The KYC page can have a login with GitHub button for auth.

As far as I know there is not way to send something on Github privately.

Maybe copilot integration. I started looking into that yesterday.

We could send it over Telegram but I don't think we have implementation for that.

Hopefully soon!

Step 5

Posting a comment when the KYC is completed would be nice but is not possible because the plugin doesn't have the Github token when it's called by the KYC provider

Shouldn't be necessary if we can display on the KYC UI that they are ready to start the task.

whilefoo commented 1 month ago

I like less friction approach.

So we risk people not completing the KYC before the issue is closed and wait for the rollup rewards to fix this problem? Unless we implement additional command /reward which calls the conversation-rewards again and the plugin checks if user now has KYC and generates a permit

The KYC page can have a login with GitHub button for auth.

So we will need our own page kyc.ubq.fi page which has login with GitHub and then redirects to the KYC provider and then back to our page

0x4007 commented 1 month ago

No to regenerate permits we just toggle the issue closed state. Pressing the button twice is less work than typing the command anyways.

whilefoo commented 1 month ago

I've checked and all of the KYC providers that I found either charge monthly minimum commitment or don't even state the price so you have to book a call with them.

0x4007 commented 1 month ago

I wonder if it makes sense to build an integration, then enable once we have paying customers.

In other news:

A CoinDesk investigation reveals North Korean IT workers have infiltrated over a dozen blockchain firms, posing cybersecurity risks and funding the regime’s nuclear program, violating U.N. sanctions and U.S. laws. - Coindesk