First of all, thank you very much for your work. The level of effort put into this project is fantastic for me; most people probably don’t realize just how much work goes into making something like this function, and honestly before looking at the code I didn't realize how much complexity was involved either. The yt2009 project probably has the most capable InnerTube implementation available (outside of libraries like YouTube.js, which isn't a ready-made backend), with support for things like SABR which isn't even implemented in most other YouTube open-source projects yet, and very advanced YouTube account authorization with even things like adding to history or channel management. I am genuinely very impressed and want to fully acknowledge the work you have done.
Second of all, due to such a robust InnerTube implementation, yt2009 has potential to, besides being a 2009 web frontend and supporting old YouTube APIs, have its own custom API format that is optimized for new third-party clients. Right now, yt2009 doesn't have a concrete API format that immediately gives all available information or have unnecessary requests. For example, the GData API has divided related videos and comments as separate requests, even though yt2009 already requests them internally together with the video information. There are other nitpicks of mine as well; for example the current API implementations commonly do not give full channel titles and instead give channel handles or ASCIIfied titles, there is no real like count, date availability is inconsistent, channel thumbnails are usually missing, etc. The YouTube account authorization (pchelper/mobilehelper) also has some limitations; the GData API often has limited results and parsing HTML is required. But it is worth noting that it is not the fault of the yt2009 project as it's simply not yet made to be used as an API for new projects.
Because of this, I would like to ask: would you be interested in having a custom API format implemented? I am happy to build this and submit a PR myself, but I wanted to check with you before starting. I understand if you do not want to have something like this, as (if I understand correctly) you haven't supported public instances of yt2009, and this project is focused to be a 2009 frontend anyway; maintaining a modern API can make it drift too far from the project's focus. A concern that may be raised is potential abuse—however, it can be solved by implementing rate-limiting or e.g. even requiring mobilehelper authorization, but the GData/Blazer/XL/Flash APIs and the HTML frontend endpoints are already sorta abusable the same way, so I don't think this is a problem that will arise with the community API specifically.
This is similar to #188, but instead of a discussion I wanted to make it a separate issue for me to solve. Again, thank you so much for your effort!
First of all, thank you very much for your work. The level of effort put into this project is fantastic for me; most people probably don’t realize just how much work goes into making something like this function, and honestly before looking at the code I didn't realize how much complexity was involved either. The yt2009 project probably has the most capable InnerTube implementation available (outside of libraries like YouTube.js, which isn't a ready-made backend), with support for things like SABR which isn't even implemented in most other YouTube open-source projects yet, and very advanced YouTube account authorization with even things like adding to history or channel management. I am genuinely very impressed and want to fully acknowledge the work you have done.
Second of all, due to such a robust InnerTube implementation, yt2009 has potential to, besides being a 2009 web frontend and supporting old YouTube APIs, have its own custom API format that is optimized for new third-party clients. Right now, yt2009 doesn't have a concrete API format that immediately gives all available information or have unnecessary requests. For example, the GData API has divided related videos and comments as separate requests, even though yt2009 already requests them internally together with the video information. There are other nitpicks of mine as well; for example the current API implementations commonly do not give full channel titles and instead give channel handles or ASCIIfied titles, there is no real like count, date availability is inconsistent, channel thumbnails are usually missing, etc. The YouTube account authorization (pchelper/mobilehelper) also has some limitations; the GData API often has limited results and parsing HTML is required. But it is worth noting that it is not the fault of the yt2009 project as it's simply not yet made to be used as an API for new projects.
Because of this, I would like to ask: would you be interested in having a custom API format implemented? I am happy to build this and submit a PR myself, but I wanted to check with you before starting. I understand if you do not want to have something like this, as (if I understand correctly) you haven't supported public instances of yt2009, and this project is focused to be a 2009 frontend anyway; maintaining a modern API can make it drift too far from the project's focus. A concern that may be raised is potential abuse—however, it can be solved by implementing rate-limiting or e.g. even requiring mobilehelper authorization, but the GData/Blazer/XL/Flash APIs and the HTML frontend endpoints are already sorta abusable the same way, so I don't think this is a problem that will arise with the community API specifically.
This is similar to #188, but instead of a discussion I wanted to make it a separate issue for me to solve. Again, thank you so much for your effort!