unixfox
commented
1 year ago That's not possible without adding a hard requirement on javascript. Essentially, we wouldn't be able to serve invidious without javascript enabled which is a must for our users. The invidious pages are not static at all and each page is rendered on the server side before given to the client.
But @SamantazFox is planning to separate the frontend and backend into two separate entities. The frontend will still communicate directly with the backend without the javascript on the client side though, so "distributed" invidious will still not be possible.
About this concept of "distributed" or "decentralization" there are already plenty of issues opened for that:
stellarpower
Switching between several different invidious instances can sometimes be quite annoying - they are on different versions, with different bugs and features; carry different user settings; are sometimes under differing load or have different bandwidth restrictions, etc.
I have seen the list of providers grow recently, so evidently people want to donate some compute time to hosting Invidious, however, it's a bit of a mixed bag with people simply hosting their own instance and having the community pick one at random to use.
I was therefore wondering about the possibility of a redesign of Invidious, that would allow current hosters to run an instance of a worker, instead of a full Invidious stack. I don't know how much of the frontend is static and how much is dynamic, so possibly this would necessitate significant redesigning; but that aside for a second, in essence I am picturing that one official invidious site would server as the point for end users, and this would then offload as much as is physically possible to the available workers.
I'm not a web developer myself, but at a simple level, I am imagining something like a static site hosted at invidious.org, to serve as the main page and the landing; and then this is set up in such a way that it. A bit like a CDN/load-balancer (at least how I picture it in my mind) - you have redundancy through several servers, all of which can take on the same role, in essence being identical, and the client gets assigned one randomly, with appropriate weighting based on current server load.
Currently we have a server health check feature, as this is what appears on the invidious site; so that would be advantageous to implementing something like this. The next related issue would probably be ensuring that workers all updated in-step, as any breaking changes would presumably need to be mirrored across all workers.
Also, on somewhat of a tangent, I am not sure how much of the YouTube API and page parsing is done in a separate library, and how much is in the Invidious sources - but having used a few different software stacks (Piped, youtube-dl, and on Android: LibreTube, SkyTube, NewPipe, ...), if each is in fact implementing these features on its own, that's a lot of code redundancy, and also, it can become very frustrating when each program then is out of step with the latest updates and fails to work. As an example, LibreTube in particular need to b up dated very regularly, before it ends up breaking often enough that it's simply easier for me to put up with the ads when I'm on my phone. I know Youtube changes their pages and everything behind the scenesoften; probably in a deliberate attempt to obfuscate - so I would like to see something like
libYouTube- one library that can be accessed from different languages ; and also, something that could easily be served in one location - to decouple changes in parsing youtube pages etc. from the apps that then present the videos to the user; download them, etc. - so Libretube would be querying the latest deployment live on a server somewhere, rather than needing me to visit F-Droid and pull in the latest app build.I mention this here for the simple reason that I think this would fit in very well with a distributed model for Invidious itself.
Any thoughts?