This is really cool, but maybe the README's disclaimer should also warn that using YouTube's private APIs is against their Terms of Service[0], specifically this section:<p><pre><code> The following restrictions apply to your use of the Service. You are not allowed to:
(...)
3. access the Service using any automated means (such as robots, botnets or scrapers) except (a) in the case of public search engines, in accordance with YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;
</code></pre>
It would be great if YouTube updated their ToS to permit this because that could unlock some really interesting innovation. Until then, devs should at least be aware that building a product with these APIs is risky.<p>[0]: <a href="https://www.youtube.com/static?template=terms" rel="nofollow">https://www.youtube.com/static?template=terms</a>
The reason I stopped integrating any API based system (FB, Twitter, etc...) into my code bases for services I don't pay for (or my customers) is because they all changed willy-nilly and broke on a regular basis.<p>This is more likely to break (be broken by google) than an official API, and those are bad enough. (hard pass on even trying this out, especially if it's good/nice I'll want to use it and kick myself later for being an idiot.)
Cool project but I wonder if the name will catch flak from the lawyers. Trademarks and all that. At they very least a big "This is not affiliated with Google/Youtube" seems like a wise precaution.
If you’re YouTube or any site, and want to stop these sort of wrappers - what’s the easiest way to do so without breaking your own site?<p>I find this task to be an interesting engineering problem.<p>A related question is if there’s an unspoofable way to detect a client.
It would be great if this had a CLI tool, so that it could be used as an alternative to yt-dlp. Or a web frontend as an alternative to Invidious, which breaks more often than not.<p>That said, I wouldn't be surprised if Google issues a C&D, or just inevitably breaks it, especially if it uses undocumented APIs.
Love this Q&A:<p><pre><code> Do I need an API key to use this?
No, YouTube.js does not use any official API so no API keys are required.</code></pre>
I'm surprised they still support video dislike via API, but have removed it from the user interface... I understand they are likely worried about backwards compatibility with the abundance of client-devices, and not inadvertently breaking some app somewhere, but why not just make it a noop...<p>Unrelated: My treadmill has the absolute worst YT client I've ever used.
I've been wanting to use the Youtube Music API to automate some personal chores (like building/cleaning playlists, etc) and was very discouraged. I actually switched to Spotify (trial) partially over it but there were a couple of other (off-topic) reasons I didn't want to stay with Spotify.<p>This looks like a wonderful tool! And it's not in Python :-D (sorry python people). Like others I'm a little concerned about breakage as youtube APIs churn. Does anyone know what Youtube's approach to backwards compatibility is for internal APIs? Some companies just wait until 98% of user's are on the new clients and then rip stuff out, but others I've worked with basically don't allow breaking the API except in important circumstances and they stick around deprecated for a while.
Worth noting that if you automate too much with this API, you'd be smart to not do it with a Google account you care about, or it'll get banned.<p>And they ban any accounts with matching recovery or verification phone numbers and email addresses too, or part of the same gsuite domain.
Sadly, I don't think it will let users view video that require login.<p>For example, some 6min show that goes on live french TV everyday got flagged and requires login to be viewed, for age reason.<p>Maybe there was curse words, or some butt-shaped thing in it?
Does the OAuth login give you full access like a cookie login?<p>Personally I'm using Firebase's private API because the public API is missing a couple of features. Currently I just regularly extract my Google cookies from Firefox and use those. But an easy login that grants access to the private API would be cleaner of course.
I'm always nervous about 3rd party API wrappers. It's basically saying "Here's the keys to my (users) Google account, please don't do anything bad". Even if it's open source, there's no guarantee there's no malicious change in version x.x.N+1