iv-org / invidious-redirect Goto Github PK

Currently it looks like the https://redirect.invidious.io/ list is there only for clearnet instances of invidious, could be interesting to have an .onion version of the same, to list the .onion instances.

If doable, would be glad to have my onion instance listed there: http://iv.daturab6drmkhyeia4ch5gvfc2f3wgo6bhjrv3pz6n7kxmvoznlkq4yd.onion/

As mentioned in #23.
Thanks

Title: Closed stream (IO::Error)
Date: 2022-12-12T23:58:49Z
Route: /watch?v=wWb7RzWdAkU
Version: 2022.12.07-abbe84cb @ (HEAD detached from origin/master)

Closed stream (IO::Error)
  from /usr/share/crystal/src/openssl/ssl/socket.cr:144:5 in 'flush'
  from /usr/share/crystal/src/io/buffered.cr:227:5 in 'close'
  from src/invidious/yt_backend/connection_pool.cr:43:9 in '_post_json'
  from src/invidious/videos/parser.cr:59:21 in 'extract_video_info:video_id'
  from src/invidious/videos.cr:366:10 in 'fetch_video'
  from src/invidious/videos.cr:354:13 in 'get_video:region'
  from src/invidious/routes/watch.cr:63:15 in 'handle'
  from lib/kemal/src/kemal/route.cr:13:9 in '->'
  from /usr/share/crystal/src/primitives.cr:255:3 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from lib/kemal/src/kemal/filter_handler.cr:21:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from lib/kemal/src/kemal/init_handler.cr:12:7 in 'process'
  from /usr/share/crystal/src/http/server.cr:498:5 in '->'
  from /usr/share/crystal/src/primitives.cr:255:3 in 'run'
  from ???

Could you fetch the server list server side?
It will make the website way better to use without JavaScript.

I've noticed a few instances going offline or slowing down substantially over the last few weeks, and I suspect it might be because users are picking the top healthy instance on the current redirect page. This surge may resource/load issues on that one instance.

What if this redirected to a random healthy instance that would have normally been shown towards the top of the list on the page today? This could be something similar, in theory, to how other load balancers work.

If you still wanted to show a list so users could manually override this behavior, show the current list with a timed redirect to a random instance after some number of seconds. (this particular part might not work without JS though..?)

How is the health percentage calculated?
A server itself can respond every time just fine and quite on time, but the instance can respond with errors caused by Google regularly.

When redirected to these instances, this can be pretty annoying. It would be nice if that would be taken into account when redirecting.

Would there be a need for URL parameters (geolocation/region, software version preference and such)?

A GitHub action need to be setup to push the container to Quay.

When JavaScript is disabled

The following problem occured in the firefox today

And the loading is never ending

The following error appears in the browser console:
entry[1].monitor.dailyRatios is undefined

Thanks for your product, hope you fix it soon

what it says on the tin

It's getting to the point where i can't use https://redirect.invidious.io, bcs it keeps loading this cloudflare-gated provider that blocks hardened web browsers and applications -> Requesting it to be removed.

Problematic providers:

1. https://invidious.kavin.rocks
2. https://invidious-us.kavin.rocks

It's part of the organisation now. The mailing list is irrelevant and references to my person and "I" should be replaced.

First, thank you all for maintaining such a fantastic project! I can focus so much more when using IV instead of having to click through and watch Ads on the main YT site. Keep up the good work!

Here's the feature idea/request: A URL parameter on invidio.us that auto-selects the first instance on the instance list and redirects the browser there.

For example: https://invidio.us/watch?v=yhu3s1ut3wM drops you on the instance selection page, where you have to pick an instance. Imagine having a parameter that you could add to the URL like 'first_instance=1', that would just auto-redirect you to the top instance on the current list. So https://invidio.us/watch?v=yhu3s1ut3wM&first_instance=1 would could land you directly on https://invidious.exonip.de/watch?v=yhu3s1ut3wM, or some other instance. I assume the instance list is somewhat randomized, so this shouldn't cause too much traffic on one instance (and might actually help spread the load better). I also expect that many people, myself included, just always click the first instance on the list anyway, so this should be strictly a user experience improvement.

Background: I use the main invidio.us site quite frequently, as I find that switching instances periodically leads to the best experience. This leads to a lot of clicking through on the first instance on the list. I've also been using a Request editor to automatically change YT urls to IV. Adding a feature like this would make the process seemless, as the Request editor could also add the URL parameter dynamically.

Thank you for considering. :)

Is there a reason our instance is missing from the Invidious site?

And mobile UI doesn't let us see the entire URLs.

Thanks

When the redirect.invidious.io instance gives user a link to "see directly on YouTube." it sometimes don't work.

For example in this link https://redirect.invidious.io/3ywlhRNX_Mc (random song) if you press any instance link it works fine but if you want to fallback in the youtube link it redirects you wrong, new url misses the "/watch?v=''" part.

idk if this is on purpose or a mistake, if somebody in the protect is comfortable with me looking forward it i would like to know.

Is your enhancement request related to a problem? Please describe.
Invidious works great for people who know about it and have Privacy Redirect or similar installed. However, when sharing links with others, it isn't possible to share a single link that works for all.

For example,

• if you were to share a link with youtube.com as the base URI, users with Privacy Redirect get Invidious working fine, but users without it get vanilla YouTube, which is not ideal.
• If you were to share a link with my-instance-uri.com as the base URI, the person sharing the link gets Invidious working fine, but this doesn't take into account the fact that different instances will work for different people due to location and such. Moreover, it doesn't respect Privacy Redirect's instance preference.
• If you were to share a link with redirect.invidious.io as the base URI, people without Privacy Redirect or similar (generally potential new invidious users) get Invidious working fine (as they don't have an instance preference as of yet), but people with Privacy Redirect have to do atleast one extra click for every link, and this doesn't respect Privacy Redirect's instance preference.

Describe the solution you'd like
https://redirect.invidious.io should either:

• have an instance preference and auto redirect users who have set the preference(this could be in a cookie or localStorage etc.)
• have an option to auto redirect to YouTube and let Privacy Redirect handle the rest.

Describe alternatives you've considered
Due to how the question was framed, alternatives are included in the question.

Additional context
None

Reasoning: distributing load on decentralized network by allowing it's use in various programs such as FreeTube.

The invidious redirect page is a very simple and straight forward site,
that should not require the use JS.

And it should thus be dropped entirely.

I think it would be beneficial for the user to know which instance is the fastest from their position.

This would lead to a better user experience and better server load balancing, as the high-ping servers wouldn't be used as much as the low-ping servers (depending on how much the redirect feature is used, of course).

The ping process could be triggered manually if there are concerns about every server getting the IP address, but otherwise I wouldn't see a problem with it being triggered automatically.