Technology

That makes Invidious' readme (which claims no YouTube APIs at all) disingenuous at the very least.

More likely, you need a lawyer. I read that TOS, and I think it applies to any YouTube API endpoint, internal or otherwise. Best of luck, because I agree with Invidious' goals...

Side note: a browser communicating with YouTube would be communicating with youtube. Not with com.google.android.youtube.api or whatever. What I'm seeing is that Invidious tries to act like the youtube service itself, which is very different from acting like a browser.

Edit: I've spent about 5 minutes looking for EU case law about this but haven't been able to find anything except un-cited references to an exception for "producing interoperable devices." Do you have sources? In the United States, at least, "clean room reverse engineering" has a pretty specific definition that follows four steps:

1. A (team of) engineers reverse-engineers an existing product, in this case, the YouTube internal API.
2. Those engineers write a specification of the product's (outwardly-visible) behavior.
3. A lawyer reviews that specification to ensure that it does not contain anything infringing on any copyrights relevant to the product.
4. A separate (team of) engineers re-implement the product according to the specification.

I don't think what you're doing meets that definition. You achieved step 1, and possibly step 2, and then didn't attempt the others. You reverse engineered something for the purpose of using it - but you haven't actually reimplemented it, which is the "clean room" part of "clean room reverse engineering." Re-implementing it would presumably require building your own server for actually hosting videos on Invidious instances.

There's quite a history of this term in the US, going back to even before Intel vs. NEC, when it was very much in the public eye. As part of arguing that case, NEC, following this procedure, produced a clean-room re-implementation of Intel's popular 8008 microprocessor's microcode. To do that, they had to re-write all of the microcode from scratch. Not figure out how to inject the 8008's microcode into their own hardware design.

Anyway, all that aside, even if what you're doing did meet the conditions of clean-room reverse engineering, I don't think it would fall under the (again, un-cited, so maybe we're talking about different things) interoperability exception in the EU. You're not producing a device/service that needs to be interoperable with other devices/services. You're producing a service with an explicit goal of operating differently.

To be clear, IANAL, but your reasoning seems shaky.