Design requirements for API free YPP signup Authorisation Flow

[zeeshanakram3]

This Issue describes the design changes required due to API-free YPP signup Authorisation Flow (#314), which is implemented in #315

In current YPP signup workflow, we have Sign up with Google button

In the new singup workflow, We would have a button for Enter Youtube video URL

After clicking on the Enter Youtube video URL, a modal can be displayed which would have a text field to enter Youtube video URL and info about the requirements of that video:

• "The video should be Unlisted"
• "The title of the video should be I want to be in YPP" I think these requirements can be displayed in the modal that currently appears after clicking on Sign up with Google

After creator enters the video URL the request would be sent to the YT-synch backend, and there are two possible outcomes

• If the verification succeeds then, the signup workflow will continue as it's currently happening
• If verification fails, then also display other possible errors in the Authorization Failed modal:
  • :white_checkmark: :x: "The video should be Unlisted_"
  • :white_check_mark: :x: "The title of the video should be I want to be in YPP"

[bedeho]

1) Can you redo this just as a sequence diagram which shows explicit calls and what paylod must be in each call and what is returned in each response. 2) How does any of this relate to actually signign up? seems that somehow account needs to be created at some point, and the attempt to do so would need allow the client to hold some sort of identifier or something that allows it to bind the signup request to prior successful presentation of a youtube URL. If it works differently it needs to anyway be explained how this first part relates ot he actual signup. 3) would signup for already created account be differnt or same?

[zeeshanakram3]

1. Can you redo this just as a sequence diagram which shows explicit calls and what paylod must be in each call and what is returned in each response.

Sure, here is the end-to-end workflow as a sequence diagram. Previously, to keep the issue simple, I only documented those steps that changed from api to api-free signup

The request & response JSON schemas are shown below (separately from the sequence diagram)

API Interaction Workflow Sequence Diagram

sequenceDiagram
    participant Creator
    participant Atlas
    participant YT-synch
    participant Faucet
    participant Orion
    participant RPC

    Creator->>Atlas: [1] Enter Youtube Video URL
    Note right of Atlas: Verify Channel request
    Atlas->>YT-synch: [2] POST /users {youtubeVideoUrl: "string"}
    Note right of YT-synch: Verify channel
    YT-synch-->>Atlas: [3] Response {id, channelHandle, ..., memberId}
    alt memberId is undefined
        Atlas-->>Creator: [4] Show mnemonic/seed phrase
        Note right of Atlas: Create membership request
        Atlas->>YT-synch: [5] POST /membership {id, youtubeVideoUrl, ...}
        YT-synch->>Faucet: [6] Captcha-free membership request
        Note right of YT-synch: Forward to Faucet
        Faucet-->>YT-synch: [7] Response {membershipId}
        YT-synch-->>Atlas: [8] Response {id, youtubeVideoUrl, ...}
    else memberId is not undefined
        Atlas-->>Creator: [4] Ask user to enter mnemonic phrase saved in the previous signup attempt to the external signer
    end

    Atlas-->>Creator: [9] Ask for email address
    Atlas-->>Creator: [10] Ask for account password
    Note right of Atlas: Create Orion account (See JSON Schema 3)
    Atlas->>Orion: [11] POST /account {signature, payload: {joystreamAccountId, ...}}
    Orion-->>Atlas: [12] Account creation confirmation { "success": true }

    Atlas->>RPC: [13] Create or Update Joystream channel (See JSON Schema 4)
    RPC-->>Atlas: [14] Channel creation/update confirmation

    Note right of Atlas: Channel Association Request (See JSON Schema 5)
    Atlas->>YT-synch: [15] POST /channels {youtubeVideoUrl, id, ...}
    YT-synch-->>Atlas: [16] Channel association confirmation

JSON Schemas

1. Verify Channel Request

POST /users Request:

{
  "youtubeVideoUrl": "string"
}

Response:

{
  "id": "string", # YT channel Id
  "channelHandle": "string",
  "channelTitle": "string",
  "channelDescription": "string",
  "channelLanguage": "string",
  "avatarUrl": "string",
  "bannerUrl": "string",
  "memberId": "string" // Membership Id (if already created in the previous signup attempt for the same channel by calling "POST /membership" endpoint) 
}

2. Create Membership Request

POST /membership Request:

{
  "id": "string", # YT channel Id
  "youtubeVideoUrl": "string",
  "account": "string",
  "handle": "string",
  "avatar": "string",
  "about": "string",
  "name": "string"
}

Response:

{
  "memberId": 0,
  "handle": "string"
}

3. Create Orion Account

POST /account Request:

{
  "signature": "string",
  "payload": {
    "joystreamAccountId": "string",
    "gatewayName": "string",
    "timestamp": 0,
    "action": "createAccount",
    "memberId": "string",
    "email": "string",
    "encryptionArtifacts": {
      "id": "string",
      "encryptedSeed": "string",
      "cipherIv": "string"
    }
  }
}

Response:

{
  "success": true
}

4. Create or Update Joystream Channel

RPC Call Request:

{
  "collaboratorId": "string",
  ...
}

Response:

Channel creation/update confirmation

5. Channel Association Request

POST /channels Request:

{
  "youtubeVideoUrl": "string",
  "id": "string", # YT channel Id
  "email": "string",
  "joystreamChannelId": 0,
  "shouldBeIngested": true,
  "videoCategoryId": "string",
  "referrerChannelId": 0
}

Response:

{
  "confirmation": "Channel association confirmation"
}

2. How does any of this relate to actually signign up? seems that somehow account needs to be created at some point, and the attempt to do so would need allow the client to hold some sort of identifier or something that allows it to bind the signup request to prior successful presentation of a youtube URL. If it works differently it needs to anyway be explained how this first part relates ot he actual signup.

As shown in the signup flow, the YT channel will be verified by the YT-synch BE using the youtubeVideoUrl provided in the request, and its verification status will be saved. Then Orion account and JS channel will be created. Finally, the binding of the Joystream channel with the previously verified YT channel happens in step 15 (Channel Association Request) where the request should again include the same youtubeVideoUrl (URL with which the channel was verified) for binding to be successful. In short , youtubeVideoUrl will be the identifier/token that the client needs to remember during the complete lifecycle of the signup workflow.

3. would signup for already created account be differnt or same?

if the Orion account (and JS membership) already exists then the signup flow would be:

• Step 1 -> Step 2 -> Step 3 -> Step 15 -> Step 16 (if Joystream channel exists)
• Step 1 -> Step 2 -> Step 3 -> Step 13 -> Step 14 -> Step 15 -> Step 16 (if Joystream channel does not exists)

[msmadeline]

Hey @zeeshanakram3 @bedeho I have a few questions related to these flows

1. Will there still be a signing up with Google? After the modal with entering video URL and with the requirements which If I understood correctly will be the first modal that we display after user click on the CTA on the YPP landing page
2. After creating the account will there still be the flow where user pick the categorie for their video etc? I feel like you skipped that part so I just need a confirmation

3. Do I understand that correctly that you want me to change the entire current "requirements"modal and change it so it asks for the video URL and has the 2 requirements that you wrote about

[zeeshanakram3]

1. Will there still be a signing up with Google? After the modal with entering video URL and with the requirements which If I understood correctly will be the first modal that we display after user click on the CTA on the YPP landing page

No, sign up with Google won't be there any longer. We will be replacing the sign up with Google approach with entering video URL

2. After creating the account will there still be the flow where user pick the categorie for their video etc? I feel like you skipped that part so I just need a confirmation

Yes, correct this flow will still exist, in fact, in this flow there should be an option for the creator to pick the language too

3. Do I understand that correctly that you want me to change the entire current "requirements"modal and change it so it asks for the video URL and has the 2 requirements that you wrote about

Well, I am unfamiliar with the design approach, so it was only my idea (i.e. asking for the video URL in "requirements" modal). I think you should design the flow as you think is the best.

[msmadeline]

@zeeshanakram3 @bedeho Hey I designed 2 new modals one for the entering Youtube video URL and one when the authorization fails. Please let me know your feedback, If approved - then I'm gonna update the user stories etc.

1. https://www.figma.com/file/oQqFqdAiPu16eeE2aA5AD5/YouTube-Partner-Program?type=design&node-id=6017-42789&mode=design&t=azGAS46X4VxuyTUy-4

2. https://www.figma.com/file/oQqFqdAiPu16eeE2aA5AD5/YouTube-Partner-Program?type=design&node-id=6018-61972&mode=design&t=azGAS46X4VxuyTUy-4

[zeeshanakram3]

@msmadeline the footer text "Gleev uses Google OAuth to get access ..." should not be present any longer as we are moving away from that approach.

Also, there will probably be a couple of new API calls/flows to properly handle failure cases (that I mistakenly omitted). I will add that too in the above sequence diagram in a while. So probably designs might change a bit due to that.

[msmadeline]

Hey @bedeho @zeeshanakram3 I recorded a quick loom video where I present the new user stories and designs that I made so far. Please let me know If I miss anything and looking forward to your feedback ✅

🎥 loom: https://www.loom.com/share/bb8a3562258b4ceaa34202ba6d71f0f9?sid=6df657ac-88c4-48d3-9296-bac77f3ec881

➡ figma file: https://www.figma.com/file/oQqFqdAiPu16eeE2aA5AD5/YouTube-Partner-Program?type=design&node-id=6035-62428&mode=design&t=5gVDQAH3zdUuDEDS-4