Remove YouTube API from user authentication

[bedeho]

Background

In order to verify that the true owner of a youtube channel is authorizing it's replication we are using the YouTube API. This means each user has to explicitly go through a flow of telling YouTube that it should connect our app to their account. This has the downsides that

• if youtube for any reason at some poin does not want to keep allowing us to do this, then YPP does not work any longer.
• creators who sign up feel much less comfortable, as they feel they are putting their channel at risk, either from sanctions from youtube, or from us somehow interrupting integrity of their channel

My understanding is that we don't need a user-level API access to do anything else, such as downloading their content or fetching any data about their channel. Technically I guess we use their youtube e.mail, but this is actually redundant, we could just ask peopel to provide a suitable email as part of normal signup.

Proposal

We remove this reliance on the API for authentication by instead just asking the user to enter their youtube channel URL, and then if it's not already in the program, we just show the user they have to add a special string to the end of their description of the channel, like "I want to be in YPP", and then when they do that, if that string is there, we just proceed as before.

There may be some other things we may need to also fetch, like size of channel or so on, but this is fetchable through other means, worst-case being to use the scraper tech that @attemka has already done for the sales page we made.

[zeeshanakram3]

My understanding is that we don't need user-level API access to do anything else, such as downloading their content or fetching any data about their channel.

Correct. Previously YT-synch used Youtube API to fetch videos/channel info, but now we have reduced the dependency on Youtube API for only verifying the ownership of the YT channel as part of the YPP signup process

Now the question comes down to the proof of ownership, i.e. how we effectively prove that the YT channel's user claims to the ownership of some channel without YouTube API

We just show the user they have to add a special string to the end of their description of the channel, like "I want to be in YPP"

Yeah, this should work in principle, and it would not require any substantial changes in the YT-synch i.e. during the signup process, YT-synch only needs to confirm the existence of a specific text in the channel description, I only have one question, from an onboarding POV is this solution better/worse off, as I believe many channels (especially high-quality ones) might not be willing to edit their YT channel's public description for YPP sign-up, but this just might be speculation from my side.

The only drawback of this approach (that I can think of) is that users won't be able to reassociate their YT channel with a different Gleev channel (since we would already have the YT channel in the program, so we wouldn't be able to verify whether the new attempt to reassociate the channel is from the legitimate user or not, unless of course will allow some different variation of text in the next attempt e.g. I want to be in YPP (2) etc). But I think this is an edge case.

Alternate Approaches

Email Verification

After the user enters their YT channel URL, we get the channel email provided in the /about section of the YT channel page (most creators provide the email address for business inquiries and stuff.)

We get that email, send some unique token to that email with some limited validity, and ask the user to enter that token when doing the signup flow.

Drwaback: This approach is significantly more complex than the approach you suggested. And it will also require email setup integration with the YT-synch.

Doing some publishing action

We could ask users to upload a short, unlisted video with a specific title or phrase on their YT channel, and then ask them to share the URL of that unlisted video, which the YT-synch BE can verify.

For the last two approaches, we can ensure that the action was indeed a response to signup flow, also since these action would have specific timestamps we can associate validity duration with such actions too.

There may be some other things we may need to also fetch, like the size of channel or so on,

Can you please elaborate on this? Any sort of channel info that is publically accessible can be easily fetched using yt-dlp

[mochet]

We could ask users to upload a short, unlisted video with a specific title or phrase on their YT channel, and then ask them to share the URL of that unlisted video, which the YT-synch BE can verify.

It is also possible to require a community post. This has a disadvantage/advantage in that only accounts that have a certain level of verification are able to do this: https://support.google.com/youtube/answer/9890437?sjid=13972600868175614401-EU

[bedeho]

as I believe many channels (especially high-quality ones) might not be willing to edit their YT channel's public description for YPP sign-up, but this just might be speculation from my side.

This is a very good point. Also, it may be hard to simply properly explain to them exactly what to do.

I think perhaps the "Doing some publishing action" suggestion is actually perhaps better, lets try that!

The only drawback of this approach (that I can think of) is that users won't be able to reassociate their YT channel with a different Gleev channel

I don't think that is

Can you please elaborate on this? Any sort of channel info that is publically accessible can be easily fetched using yt-dlp

Ok, I was just speculating, but what about e-mail, where would we get that? I think most youtube accounts will not have a public email, or at least a substantial share will not.

Should we move away from using the Youtube level email?
Do we actually need that for anything? In fact, it may be that the user wants to use a separate email for their Gleev account, for notifications and similar things, to their Youtube email. Today I believe the youtube email is automatically used for both?

---

We have a separate problem which has to do with a flaw in the signup flow, where there is a possibility of a session failing at certain stages, perhaps we can tackle that at the same time?

---

Why don't you try to make a proof of concept version of the yt-synch API based on this approach, and confirm that it works, is reliable, how long it takes to run, etc.

When that is ready, we probably need to describe the new API in a way which allows our designer to redesign the user flow