Full channel onboarding

[bedeho]

Basically infra part of this: https://github.com/Joystream/atlas/issues/4091

So backend fetches all images, titles, descriptions, etc. and is able to create them on joystream chain and upload assets.

[zeeshanakram3]

Here's a proposal for an improved channel onboarding workflow. Keep in mind this approach still includes the interaction with the browser signer, however, the new workflow is much simpler and does not involve much interaction to populate the metadata fields.

Current Workflow

1. Installing signer (if not already installed)
2. Setting Up Membership through Atlas (Signing involved)
   • Provide member avatar asset (optional)
   • Provide member handle (required)
3. Setting Up Channel through Atlas (Signing involved)
   • Provide channel metadata
   • Provide channel assets
4. Creator authorizes Atlas app using Google Oauth workflow, app gets authorizationCode.
5. Atlas calls YT-synch BE's POST /users endpoint with authorizationCode to verify the user's channel ownership, and as well as the channel's onboarding requirements.
6. Atlas calls POST /channels endpoint providing the joystreamChannelId of the newly created channel (in step 3) that should be linked with the verified Youtube channel.
7. Atlas asks the channel owner to add JSG collaborator into their Joystream channel (Signing involved)

Notice in the current workflow, there singing is involved (twice) in channel creation (step 3), and during adding the collaborator account (step 6), I think should be done within the same step, i.e. specifying the JSG collaborator in the channel creation input.

Proposed Workflow

1. Installing signer (if not already installed)
2. Creator authorizes Atlas app using Google Oauth workflow, app gets authorizationCode
3. Calls YT-synch BE's POST /users endpoint with authorizationCode to verify channel ownership & onboarding requirements
   • API returns the MembershipMetadata, handle, and data object params for member avatar photo already set in the metadata. The membership handle will be set to the corresponding youtube creator handle [see Handles overview], and the membership avatar photo to the Youtube channel avatar.
   • API returns the encoded ChannelCreationParameters, with all the channel metadata(title, description etc.), data object info for avatar/cover photos, and JSG collaborator memberId part of channel creation parameters
4. Atlas setup the membership & channel on-chain based on the extrinsic input parameters returned by the YT-synch BE. (Signing involved)
5. Atlas calls POST /channels endpoint providing the joystreamChannelId of the newly created channel that should be linked with the verified Youtube channel.
   • YT-Synch uploads the pending assets for the both channel & member

[bedeho]

• Thanks for summarizing the distinction between current and future flow.
• My assumption is that we ship this with new signer-free key management, this means we do not require users to install a signer first. As a UX side-note, even if we wanted to release this with signer being only option, its better to do the easy stuff earlier in the flow, like have the person do Google auth and submit an email and so on, so that they are more committed to completing once the risky step comes, and if they bounce we have a chance to re-engage them later, using the captured email for example.
• Remember that Atlas must be given a chance to allow user to intervene when specifying fields where value must be unique within the blockchain. I now forget, but I think membership handles are unique, and perhaps also channel handles? I have totally lost track. Either way, whatever is unique on-chain cannot be automatically set by backend, because if there is a conflict between what YouTube metadata has and what lives in chain, then backend must compute some sort of alternative version, and the user may later be confused or not recognize where this alternative version came from. As an example. Lets say you are Bob on YouTube, but using this string on Joystream will not work, because it is taken, so backend just generated Bob123 and used that. Now, if the user at some point was to see Bob123 in Gleev, they will be confused. Anything which is not unique, we can just straight up copy from YouTube and hide from user in YPP flow, and then later if they want to edit it they can.
• In the interest of simplicity, should we just assume that if you want to enter into YPP, you are always obliged to do it for a fresh member and fresh channel under that member? You are already assuming that here, but it just seems to me to be worth stating explicitly, because the number of variations get quite large otherwise, and it will require a lot of design work to accomodate that in Atlas. I am talking of cases where
  • user has a member, possibly multiple channels, but wants to make a new channel under this member for YPP.
  • user has a member and a channel, but wants to connect this specific channel in YPP. My sense is, now that we add the signer vs. non-signer as a new dimension to the state of a user, the amount of flows and complexity is going to be way too high, and we are best served just slimming everything way down. I think we probably already allow too much in terms of YPP flows.

Just to summarise, this would be my mental model of the state machine over user states. Please weigh in @KubaMikolajczyk @dmtrjsg @attemka

[attemka]

@bedeho

Lets say you are Bob on YouTube, but using this string on Joystream will not work, because it is taken, so backend just generated Bob123 and used that

The channel names aren't unique, so this will be possible. However, I don't know if user should be able to change his channel name after he opted in with YPP?

you are always obliged to do it for a fresh member and fresh channel under that member?

Of course, we'll benefit from this on the development side and we'll lower the amount of usecases that are needed to be solved. However, from the UX perspective, I'm not sure that it'll be very user friendly. I think user needs to gain some basic understanding of the platform and its possibilities before he'll want to opt-in his YT channel. He might upload bunch of videos during this period, which means he'll need to re-upload them to his new channel with YPP enabled. This might be very frustrating.

[bedeho]

I don't know if user should be able to change his channel name after he opted in with YPP?

I don't think this is an issue, we identify htem using a unique yt-synch ID I believe, and there is also on-chain channel id which is registered, as well as an immutable youtube id.

This might be very frustrating.

Yes, while this edge case is theoretically possible, its not worth it to preserve. We see how hard we have to work to just reach and convert people to start journey, so trading off in any way in favor of some hypothetical future creator who wants to engage in labor intensive manual work is not a good tradeoff for us.

[zeeshanakram3]

My assumption is that we ship this with new signer-free key management,

Not really aware of how the signer-free key management will work in detail, I believe the user accounts will come into play for that? Anyways, if the creator wants to have self-custody/self-management do we still want to have the signer-free workflow for YPP onboarding?

As a UX side-note, even if we wanted to release this with signer being only option, its better to do the easy stuff earlier in the flow,

Sure it makes sense to do the Google authentication successfully before installing a signer (if the user hasn't already installed it)

If they bounce we have a chance to re-engage them later, using the captured email for example.

This is actually a very good point. When a creator authorizes the Gleev app using the Oauth workflow, the app gets the authorization code which it sends to the YT-synch's /users API endpoint for channel verification. Next, if the channel verification is successful the user's information including the email is stored database so ideally they should be able to engage later even if they bounce off. But currently, Atlas doesn't deal with that so if users don't complete the whole workflow end-to-end they should start again from the very first step even if they have already gone through the Google Oauth workflow and verified with the backend.

Remember that Atlas must be given a chance to allow user to intervene when specifying fields

Okay, I get the point so basically I will adjust the API endpoint to return the response such that instead of returning serialized MembershipParameters & ChannelCreationParameters, it should return all the fields that can be automatically set from FE by providing a choice to the creator to select/change the fields, such as membership handle, channel title, channel description, assets, etc.

// `/users` response
{
  "membershipCreationParams": {
    "handle": "YOUTUBE_CREATOR_HANDLE"
    "metadata": {
     "avatarUrl": "YOUTUBE_CREATOR_AVATAR_URL" 
    }
  },
  "channelCreationParams": {
    "collaborators": ["JSG_YT_SYNCH_COLLABORATOR_ID"]
    "assets": [...] // Channel avatar & cover photo data-object params
  }
}

In the interest of simplicity, should we just assume that if you want to enter into YPP, you are always obliged to do it for a fresh member and fresh channel under that member? You are already assuming that here

Yes, I was already assuming that the creator signing up for the YPP program will follow steps end-to-end including creating a membership and channel. But obviously, as you mention they might already have the membership/channel set up so for those creators the workflow will diverge from point 6 (see diagram below). And will directly jump to a point 10

Also, I think the use cases you mention won't create any problems for the proposed workflow since I believe the use cases were already being handled in the YPP v1 (Atlas guys to confirm) so even if the user has multiple channels and they want to select one from these or create a new one to connect with the verified YT-channel, the flow should work.

——

sequenceDiagram
    Creator->>+Gleev: 2. authorizationCode
    Gleev->>+Creator: 1. authorization request
    Gleev->>+YT-synch: 3. calls `/users` with authorizationCode
    YT-synch->>+YT-synch: 4. captures the YT channel info. And check if it meets the onborading requirements. 
    YT-synch->>+Gleev: 5. returns the YT user & channel info that can be used to populate the on-chain metadata.
    Gleev->>+Creator: 6. Asks the creator whether to create a new membership/channel or select from the existing one 
    Gleev->>+Creator: 7. If the creator decides to a new membership/channel, ask him to customize the metadata fields (defaults to corresponding YT metadata returned in step 5.)
    Creator->>+Creator: 8. Installs signer
    Gleev->>+Joystream: 9. Creates on-chain Membership/Channel
    Gleev->>+YT-synch: 10. calls POST `/channels` endpoint providing the joystreamChannelId
    YT-synch->>+YT-synch: 11. uploads the pending assets

[bedeho]

Not really aware of how the signer-free key management will work in detail, I believe the user accounts will come into play for that?

Yes.

Anyways, if the creator wants to have self-custody/self-management do we still want to have the signer-free workflow for YPP onboarding?

YPP onboarding now requires the user to use non-signer based key management, as you see in the diagram above.

Next, if the channel verification is successful the user's information including the email

Sorry, what email does youtube provide us? is that the google email account used for the account?

But currently, Atlas doesn't deal with that so if users don't complete the whole workflow end-to-end they should start again from the very first step even if they have already gone through the Google Oauth workflow and verified with the backend.

But if the user comes back and tries to reauthenticate with google at a later second time, that will still work, right? they won't get blocked fro dropping out?

[zeeshanakram3]

Sorry, what email does youtube provide us? is that the google email account used for the account?

If the creator has multiple YT channels, and he is authenticating the primary Youtube channel to Gleev, then Google will provide google email account. Otherwise some system generated email associated with the brand-account will be provided

For example, If I authenticate my main account/channel Zeeshan Akram then my Google email will be shared will the app. If I authenticate Test Channel, then a brand account email like this test-channel-00967@pages.plusgoogle.com will be shared.

But if the user comes back and tries to reauthenticate with google at a later second time, that will still work, right? they won't get blocked fro dropping out?

Yes, they can authenticate as many times as they want, the OAuth authentication flow is agnostic to the past authentication state. And it's the responsibility of the client App to decide whether to ask the creator to re-auth depending on the fact whether previous authentication was successful or not

[dmtrjsg]

The diagram @zeeshanakram3 put together in the comment above looks good to me. Not much to add here after reading your exchange of comments. Let's get this out together with the user accounts!

@KubaMikolajczyk FYI this diagram as a basis for the flow that we discussed today>