Onboarding - Capture which app was used to activate an @ sign

[tinashe404]

Lead: @cconstab

We are currently looking into the developer program and how they earn commissions. Since we don't have in app purchases at the moment, in order to determine which apps should get commissions on paid atsigns, we need the onboarding widget to report which app was used to activate a paid atsign.

A suggestion from Ashish was that maybe it could be stored in the atsign secondary or atcompany secondary or hit a webhook so that he can know which app the atsign was activated in.

[gkc]

Decision to be pinned down and documented during this sprint

[yahu1031]

Suggestions:

Idea 1

We can pass namespace to the req headers on API calls.

Idea 2

We can add a key in atKeys

{
  "aesPkamPublicKey": "...",
  "aesPkamPrivateKey": "...",
  "aesEncryptPublicKey": "...",
  "aesEncryptPrivateKey": "...",
  "selfEncryptionKey": "...",
  "@someatsign": "...",
  "activatedFrom": "namespace"
}

So when the atKeys file was generated, we can put another key like activatedFrom@someatsign and namespace as values in their secondary.

Drawback

Idea 2 will increase the storage(a little bit though).

[sitaram-kalluri]

During onboarding, After performing the initial auth, create a self key what will have namespace as a value and store into local-secondary and sync to remote secondary.
Have an API exposed which would the return value from the cloud secondary.

[VJag]

Solution 1:

API key per app/payee

Description:

Through some process, a developer logs into atsign.dev and gets an API key for his/her app. He also shares his details in order to be paid for the @sign commissions.

This key is then used to activate the @Signs. Since each app/payee is uniquely identified by a key, it is possible to identify and pay them.

In this approach securing the key is up to the developer. We will have the issue of someone decompiling the app and getting the key. Till we have an approach to solving that we have to use this approach.

Solution 2:

Extend activation API to include appName

Description:

In this approach, we need to extend the activation to include an additional parameter called "appName". it would the responsibility of the developer to pass the right value. We still need the keys for activation. But the only real use of the keys is to know that the app went through a certain process with us and probably even to rate limit etc..

Even in this approach, the developer needs to log in to the atsign.dev to get an API key. We still need a way for the developer to share the payment details. The only advantage here is probably we do not have to generate API keys per app.

activation API sample params:

Ex1:

newAtSign: atsita
appKey: k123
appName: buzz

Ex2:

newAtSign: atjagan
appKey: k123
appName: atmosphere

[VJag]

We have burned 5 story points and discussed the approach in an architecture call. This needs to be carried to the next sprint.

[murali-shris]

moving this to backlog since issue has been carried over multiple sprints with no concrete approach

[gkc]

Should be able to make progress on this once atsign-foundation/at_server#686 has been implemented

[ksanty]

@murali-shris above ticket is closed should we re-prioritize to high to try and finish PR43?

[murali-shris]

@murali-shris above ticket is closed should we re-prioritize to high to try and finish PR43?

yes @ksanty

[athandle]

@murali-shris do you have any update on this? How you are planning to do this?

[ksanty]

@athandle can you please add outcome notes from today's architecture discussion, so we can reclassify priority? TY

[athandle]

@ksanty I am closing this ticket, will take care with https://github.com/atsign-company/at_handle_registrar_web/issues/140