Add invidious companion support #4985

unixfox · 2024-10-07T09:57:54Z

Description

Invidious companion is the new tool created for the retrieval of the YouTube streams: https://github.com/iv-org/invidious-companion

Invidious will not handle the videos streams retrieval anymore, as it has become as burner for the Invidious team to adapt. Instead, invidious companion will be based on https://github.com/LuanRT/YouTube.js which is the most up to date when it comes to video streams retrieval.

This allows us to spend more time on actually improving the Invidious frontend.

What does this PR do?

Invidious send the /player request to Invidious companion in HTTP(S). Invidious companion does all of its magic then Invidious does the usual parsing of the player endpoint.

Invidious also delegate the work of latest_version, /api/manifest/dash/id and /videoplayback to Invidious companion.

What does invidious companion do

You can set multiple invidious_companion. Allowing you to utilize multiple external servers
It supports SOCKS proxy - related to Allow to use proxies (HTTP(s) & socks) #301
There is a plan to support multiple proxies: handle the ability to use multiple proxies invidious-companion#5
There is no need to use inv_sig_helper as the program automatically handle the deciphering.
There is no need for youtube-trusted-session-generator as the program automatically generate a po_token at a configurable frequency.
You can logging with a yt account

Incompatibilities

You can't use inv_sig_helper with invidious companion

How to try?

Run Invidious companion with a secret key: https://github.com/iv-org/invidious-companion?tab=readme-ov-file#run-locally
Configure Invidious companion in the config.yaml and with the same secret key:

invidious_companion:
  - http://127.0.0.1:8282
invidious_companion_key: myBeautifulKey

Run Invidious

Fixes

Fixes [Bug] "This helps protect our community." - "Please sign in to confirm you’re not a bot" #4734 - Any new issue around YouTube breaking the /player will know have to happen on https://github.com/iv-org/invidious-companion/issues
Fixes [Enhancement] Add support for multiples audio tracks #2007 - youtube.js provide DASH files with multi audio support
Fixes [Bug] Auto-generated subtitles no longer display in the video player #4660 - youtube.js provide the captions
Fixes [Feature request] Add option to sign in to Google account (as workaround for "Please sign in" blocking playback) #4977 - youtube oauth is available thanks to youtube.js
To investigate: [Bug] DASH quality on safari iOS #2236
To investigate: [Bug] DASH on Safari macOS is broken - Playback cannot continue. No available working or supported playlists. #4199
To investigate: [Feature request] Add support for transcripts #2564
To investigate: [Enhancement] Throw an error on Widevine content #3021

Related to

[Enhancement] Print message about guide on how to configure invidious companion when "This helps protect our community." message is found #4838

src/invidious/yt_backend/youtube_api.cr

src/invidious/videos/parser.cr

src/invidious/videos.cr

src/invidious/routes/watch.cr

SamantazFox · 2024-11-05T13:16:39Z

src/invidious/routes/api/manifest.cr

+    if local && CONFIG.invidious_companion
+      return env.redirect "#{video.invidious_companion["baseUrl"].as_s}#{env.request.path}?#{env.request.query}"
+    end


As the get_video() call above already talks to the companion and gets playable URLs, why still redirect to the companion manifest handler? Why not let invidious generate the manifest?

PS: I realized that there is an important oversight here: what if the video object (e.g returned from cache) doesn't have a companion field, or the companion base URL is not present anymore in the config?

PPS: Why handling that case at all when the URL is already replaced in components/player.ecr?

There are multiple reasons:

One may configure a proxy in invidious_companion. And invidious companion is going to handle multiple proxies soon, so this can't be handled inside Invidious: handle the ability to use multiple proxies invidious-companion#5

DASH manifest generation from youtube.js include way more things than invidious. which includes multi-language audio support, see here for more: https://github.com/LuanRT/YouTube.js/blob/4e9c2a585bf84751dd4e3964f70fba284c8b8e38/src/utils/DashManifest.tsx#L68-L267

If an external program relies on the dash api, it makes more sense to redirect this request to Invidious companion because it avoids making unnecessary process in invidious as Invidious companion is the one requesting the video streams from YouTube.

One may configure multiple invidious companion, we need to make sure that the video stream used is from the same public IP address that generated the video stream.

In the design plan, I said that everything related to the video retrieval should be handled now in invidious companion. It doesn't make a lot of sense to handle all the logic explained above in invidious.

One may configure a proxy in invidious_companion. And invidious companion is going to handle multiple proxies soon, so this can't be handled inside Invidious

Unless this is done transparently to the end user (e.g with NGINX rules), the CSP header will need to reflect the use of these external proxies, and so Invidious will need to take care of it.

DASH manifest generation from youtube.js include way more things than invidious. which includes multi-language audio support

But is this compatible with videoJS? Our DASH manifest is missing multiple formats because of that.

If an external program relies on the dash api, it makes more sense to redirect this request to Invidious companion because it avoids making unnecessary process in invidious as Invidious companion is the one requesting the video streams from YouTube.

Invidious already requests and parses the whole /player response returned by the companion (if it wasn't already in cache) so I don't think this will represent much more processing.

One may configure multiple invidious companion, we need to make sure that the video stream used is from the same public IP address that generated the video stream.

For an API user, all URLs should already have that companion as the host, and for a web user, all the relevant URLs should already be handled in components/player.ecr. Am I right?

If so, the only way to access invidiou's own /latest_version and manifest endpoints would be willingly by a malicious or careless API user, so broken streams are a non-problem here imo.

First of all, I would like to say that I have been in your thinking situation. I had long thoughts about the advantages and the disadvantages of each implementation. This current implementation outweighs the one where Invidious handle almost all the logic and Invidious companion is just "dumb proxy".

Also, invidious companion is not entirely new, it's actually based on the ideas of invidious-stripped-down. A project that I have used for 2 years on yewtu.be in order to replace some functions of Invidious. For really improving the performance and user experience of my instance.

Unless this is done transparently to the end user (e.g with NGINX rules), the CSP header will need to reflect the use of these external proxies, and so Invidious will need to take care of it.

Already does in https://github.com/iv-org/invidious/pull/4985/files#diff-a86ced8aa99e3403588538decc008851d3d33dfadbb00d392d5ec8b4696f7df4

But is this compatible with videoJS? Our DASH manifest is missing multiple formats because of that.

Yes. I have used it for 2 years on yewtu.be. I'm stripping out the codec that do not work: https://github.com/iv-org/invidious-companion/blob/master/src/routes/invidious_routes/dashManifest.ts#L41-L43

If an external program relies on the dash api, it makes more sense to redirect this request to Invidious companion because it avoids making unnecessary process in invidious as Invidious companion is the one requesting the video streams from YouTube.

Invidious already requests and parses the whole /player response returned by the companion (if it wasn't already in cache) so I don't think this will represent much more processing.

The benefit of handling latest_version and /api/manifest/dash/id/ is that you can more easily handle all the edge cases in invidious companion itself, no need to add more logic in Invidious. Especially in a time when YouTube is evolving rapidly, we want to keep the pace thanks to youtube.js.

For an API user, all URLs should already have that companion as the host, and for a web user, all the relevant URLs should already be handled in components/player.ecr. Am I right?
If so, the only way to access invidiou's own /latest_version and manifest endpoints would be willingly by a malicious or careless API user, so broken streams are a non-problem here imo.

My number one priority is users using Invidious directly. We can think about API users later. Our main user base uses our frontend.

It doesn't mean that developers using the API are forever forgotten. I have ideas but for the moment, if invidious companion is configured then the video streams given through the API may not always work, especially when "proxying" through the same public IP address is needed.

I'm sorry, but a day is only 24 hours and at the moment I'm a single developer trying to improve the overall usability of Invidious through youtube.js. I can't deal with all the cases at the same time. Happy to receive more help for contribution!

Already does in https://github.com/iv-org/invidious/pull/4985/files#diff-a86ced8aa99e3403588538decc008851d3d33dfadbb00d392d5ec8b4696f7df4

The problem is that it add the companion's domains to the CSP, but not the companion's proxies themselves.

The benefit of handling latest_version and /api/manifest/dash/id/ is that you can more easily handle all the edge cases in invidious companion itself [...]
[...]
My number one priority is users using Invidious directly. We can think about API users later. Our main user base uses our frontend.

My question was about the necessity of adding this redirect logic on these endpoints, where they should never be called in the first place, as none of the URLs in the /watch page should lead to invidious in the first place!

Already does in #4985 (files)

The problem is that it add the companion's domains to the CSP, but not the companion's proxies themselves.

This adds in the CSP the baseUrl: https://github.com/iv-org/invidious-companion/blob/master/config/default.toml#L5 which is given by invidious companion in the JSON reply. This domain is the same domain that which videojs will use for either latest_version or dash manifest api requests or videoplayback request.

We are not adding the URL passing in here: https://github.com/iv-org/invidious/pull/4985/files#diff-b68cf7cb2cb2dbd2275444b03cdc238962e05b5ccff0b89ba34b1f9126f39187R71

invidious_companion: - http://127.0.0.1:8282

My question was about the necessity of adding this redirect logic on these endpoints, where they should never be called in the first place, as none of the URLs in the /watch page should lead to invidious in the first place!

You always have stuff that use these endpoints directly without going through the frontend. It's to make sure that we are using invidious companion all the time.

download function/button in invidious

bots

apps that use latest_version or dash manifest api instead of the official api of invidious

It's to make sure that we avoid sending wrong requests to youtube servers and the IP get banned for that.

This adds in the CSP the baseUrl [...] which is given by invidious companion in the JSON reply

I got that ^^ But if the companion has say proxy1.example.com and proxy2.example.com set, those won't be added to the CSP. Unless this is completely transparent to invidious (= the companion forwards the request to the proxies itself, and invidious only ever connects to http://127.0.0.1:8282)

It's to make sure that we avoid sending wrong requests to youtube servers and the IP get banned for that.

Fair enough!

I have rewritten some part. Let me explain.

If you ENABLE invidious_companion then by default in Invidious:

/api/manifest/dash/id/ is blocked

/latest_version is blocked

This makes sense, as those endpoints are not used in Invidious if Invidious companion is enabled. This is to avoid any tries to load some video stream through the incorrect IP and making the requests suspicious to YouTube servers.

But for the "downloads" feature, all requests will now be straight sent to latest_version endpoint of invidious companion.

I know this does not yet download the video file directly but the user can do it by clicking on the download feature in their browser and this works. It's being tracked in iv-org/invidious-companion#13

In my opinion this is not a dealbreaker as the Invidious download function is somewhat not useful anymore since the removal of hd720. Maybe in the future we could look into adding ffmpeg combining video and audio on the fly, but right now I'm prioritizing giving back more stability to Invidious.

src/invidious/routes/video_playback.cr

src/invidious/yt_backend/youtube_api.cr

src/invidious/views/components/player.ecr

unixfox · 2024-11-05T17:36:53Z

Feedback from @Fijxu:
Try to handle busted or IP blocked invidious companions.

src/invidious/videos/parser.cr

SamantazFox · 2024-11-07T16:02:18Z

src/invidious/routes/api/manifest.cr

+    if local && CONFIG.invidious_companion
+      return env.redirect "#{video.invidious_companion["baseUrl"].as_s}#{env.request.path}?#{env.request.query}"
+    end


Already does in https://github.com/iv-org/invidious/pull/4985/files#diff-a86ced8aa99e3403588538decc008851d3d33dfadbb00d392d5ec8b4696f7df4

The problem is that it add the companion's domains to the CSP, but not the companion's proxies themselves.

The benefit of handling latest_version and /api/manifest/dash/id/ is that you can more easily handle all the edge cases in invidious companion itself [...]
[...]
My number one priority is users using Invidious directly. We can think about API users later. Our main user base uses our frontend.

My question was about the necessity of adding this redirect logic on these endpoints, where they should never be called in the first place, as none of the URLs in the /watch page should lead to invidious in the first place!

src/invidious/videos/parser.cr

Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>

…_version

SamantazFox · 2024-11-19T16:14:35Z

src/invidious/routes/watch.cr

    elsif itag = download_widget["itag"]?.try &.as_i
+      itag = itag.to_s


Suggested change

elsif itag = download_widget["itag"]?.try &.as_i

itag = itag.to_s

elsif itag = download_widget["itag"]?.try &.as_i.to_s

SamantazFox · 2024-11-19T16:28:01Z

src/invidious/routes/embed.cr

+    if (!CONFIG.invidious_companion.empty?)
+      env.response.headers["Content-Security-Policy"] =
+        env.response.headers["Content-Security-Policy"]
+          .gsub("media-src", "media-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)
+          .gsub("connect-src", "connect-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)
+    end


Proposed improvements:

Base the if condition on the presence of the companion base URL, rather than the current config (reduces the risk of breaking videoplayback on cached videos)

Use string interpolation (faster)

Keep usage of .not_nil! to a minimum, as recommended by Ameba

Suggested change

if (!CONFIG.invidious_companion.empty?)

env.response.headers["Content-Security-Policy"] =

env.response.headers["Content-Security-Policy"]

.gsub("media-src", "media-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)

.gsub("connect-src", "connect-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)

end

if companion_base_url = video.invidious_companion.try &.["baseUrl"].as_s

env.response.headers["Content-Security-Policy"] =

env.response.headers["Content-Security-Policy"]

.gsub("media-src", "media-src #{companion_base_url}")

.gsub("connect-src", "connect-src #{companion_base_url}"

end

~~How do you do without .not_nil! though? I had a hard time understand how. Crystal makes my brain hurt.~~

the solution in #4985 (comment) will probably help

SamantazFox · 2024-11-19T16:32:12Z

src/invidious/routes/watch.cr

+    if (!CONFIG.invidious_companion.empty?)
+      env.response.headers["Content-Security-Policy"] =
+        env.response.headers["Content-Security-Policy"]
+          .gsub("media-src", "media-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)
+          .gsub("connect-src", "connect-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)
+    end


Same suggestion as above:

Suggested change

if (!CONFIG.invidious_companion.empty?)

env.response.headers["Content-Security-Policy"] =

env.response.headers["Content-Security-Policy"]

.gsub("media-src", "media-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)

.gsub("connect-src", "connect-src " + video.invidious_companion.not_nil!["baseUrl"].as_s)

end

if companion_base_url = video.invidious_companion.try &.["baseUrl"].as_s

env.response.headers["Content-Security-Policy"] =

env.response.headers["Content-Security-Policy"]

.gsub("media-src", "media-src #{companion_base_url}")

.gsub("connect-src", "connect-src #{companion_base_url}"

end

SamantazFox · 2024-11-19T16:55:19Z

src/invidious/routes/watch.cr

-      return Invidious::Routes::VideoPlayback.latest_version(env)
+      if (!CONFIG.invidious_companion.empty?)
+        video = get_video(video_id)
+        return env.redirect "#{video.invidious_companion.not_nil!["baseUrl"].as_s}/latest_version?id=#{video_id}&itag=#{itag}&local=true"


env.params.query is a regular HTTP::Params, so by doing a string interpolation, its .to_s method will be called, allowing to pass all parameters in one shot, with the proper encoding:

Suggested change

return env.redirect "#{video.invidious_companion.not_nil!["baseUrl"].as_s}/latest_version?id=#{video_id}&itag=#{itag}&local=true"

return env.redirect "#{video.invidious_companion.not_nil!["baseUrl"].as_s}/latest_version?#{env.params.query}"

With this, the suggestion right above can be ignored, and itag line above can be reverted.

~~On a side note, this implies that the invidious compacnion will take care of file downloads. Is that intended?~~
Nevermind, I saw #4985 (comment)

SamantazFox · 2024-11-19T16:57:31Z

src/invidious/videos.cr

+  def invidious_companion : Hash(String, JSON::Any)?
+    info["invidiousCompanion"]?.try &.as_h
+  end


I realized that the following might be better, to avoid using .not_nil! everywhere, and instead rely on the Hash's []? method:

Suggested change

def invidious_companion : Hash(String, JSON::Any)?

info["invidiousCompanion"]?.try &.as_h

end

def invidious_companion : Hash(String, JSON::Any)

info["invidiousCompanion"]?.try &.as_h || {} of String => JSON::Any

end

ha yes crystal will be happier :).

SamantazFox · 2024-11-19T17:10:36Z

src/invidious/routes/api/manifest.cr

+    if !CONFIG.invidious_companion.empty?
+      return error_template(403, "This endpoint is not permitted because it is handled by Invidious companion.")
+    end


What do you think here to redirect to a random invidious companion, rather than display an error message? Sure, if there are multiple companions, we might not hit the same that initially loaded the watch page, but it might make playback smoother.

The issue is that you have to do a request to a random invidious companion for knowing its "public" URL. I had ideas to include the public URL inside the config.yml. But my poor Crystal knowledge limited me due to the new URIArrayConverter.

Something like:

invidious_companion: - http://127.0.0.1:8282: public_url: https://companion1.invidious.com

I want to avoid doing unnecessary requests to invidious companion.

http://127.0.0.1:8282 is the internal address that invidious uses to communicate with invidious companion. but the companion could very well be on another server, and so having a config like this can exist:

invidious_companion: - http://10.0.0.2:8282: public_url: https://companion1.invidious.com

10.0.0.2 is another server and 10.0.0.0/24 is an internal network faster than the internet network. example: https://www.ovhcloud.com/en/public-cloud/private-network/

SamantazFox · 2024-11-19T17:12:03Z

src/invidious/yt_backend/youtube_api.cr

+  ) : Hash(String, JSON::Any)
+    headers = HTTP::Headers{
+      "Content-Type"  => "application/json; charset=UTF-8",
+      "Authorization" => "Bearer " + CONFIG.invidious_companion_key,


Suggested change

"Authorization" => "Bearer " + CONFIG.invidious_companion_key,

"Authorization" => "Bearer #{CONFIG.invidious_companion_key}",

SamantazFox · 2024-11-19T17:15:29Z

src/invidious/yt_backend/youtube_api.cr

@@ -500,7 +500,11 @@ module YoutubeAPI
      data["params"] = params
    end

-    return self._post_json("/youtubei/v1/player", data, client_config)
+    if !CONFIG.invidious_companion.empty?
+      return self._post_invidious_companion("/youtubei/v1/player", data)


Just as a side note here: because we've a dedicated function to call the companion, we're not forced to use the same URL path as youtube! The path can even be hardcoded (= one less argument required), as we're sure it will never change.

but it's possible that we could send more path than /youtubei/v1/player. we do not know the future.

/youtubei/v1/player is because I want invidious companion to be compatible with other projects: iv-org/invidious-companion#4

SamantazFox · 2024-11-19T17:20:44Z

src/invidious/yt_backend/youtube_api.cr

+      if (response.status_code != 200)
+        raise Exception.new("Error while communicating with Invidious companion: \
+                              status code: " + response.status_code.to_s + " and body: " + body)
+      end


Using string interpolation + .dump on the body, as it 1. quotes the data and 2. prevents control and non-ASCII characters from breaking the terminal/log file:

Suggested change

if (response.status_code != 200)

raise Exception.new("Error while communicating with Invidious companion: \

status code: " + response.status_code.to_s + " and body: " + body)

end

if (response.status_code != 200)

raise Exception.new(

"Error while communicating with Invidious companion: \

status code: #{response.status_code} and body: #{body.dump}"

)

end

SamantazFox · 2024-11-19T17:25:38Z

src/invidious/yt_backend/youtube_api.cr

+    if body.nil?
+      raise InfoException.new("Error while communicating with Invidious companion: no response data.")
+    end


This is not required, as body is always String, because

You're using response.body and not response.body?

You're already catching any potential errors above!

unixfox mentioned this pull request Oct 13, 2024

trying to only use next endpoint for the major data #5003

Draft

4 tasks

unixfox force-pushed the invidious-companion branch 2 times, most recently from 7efa8f7 to 194fb72 Compare October 20, 2024 00:11

unixfox force-pushed the invidious-companion branch from f6d8ddc to a63fca8 Compare November 1, 2024 20:34

unixfox changed the title ~~add invidious_companion option~~ Add invidious companion support Nov 1, 2024

unixfox mentioned this pull request Nov 1, 2024

[Enhancement] Fix the decrypt function - the decryption of the encrypted videos #3245

Closed

unixfox requested a review from syeopite November 1, 2024 21:19

unixfox marked this pull request as ready for review November 1, 2024 21:19

unixfox requested review from SamantazFox and a team as code owners November 1, 2024 21:19

syeopite requested changes Nov 5, 2024

View reviewed changes

src/invidious/yt_backend/youtube_api.cr Outdated Show resolved Hide resolved

src/invidious/yt_backend/youtube_api.cr Outdated Show resolved Hide resolved

src/invidious/yt_backend/youtube_api.cr Outdated Show resolved Hide resolved

SamantazFox reviewed Nov 5, 2024

View reviewed changes

SamantazFox reviewed Nov 7, 2024

View reviewed changes

unixfox force-pushed the invidious-companion branch from 2683b24 to 37df2b4 Compare November 8, 2024 19:28

unixfox marked this pull request as draft November 8, 2024 22:44

syeopite reviewed Nov 9, 2024

View reviewed changes

src/invidious/videos/parser.cr Outdated Show resolved Hide resolved

unixfox mentioned this pull request Nov 10, 2024

error[E0425]: cannot find value JS_EVAL_FLAG_ASYNC in module qjs iv-org/inv_sig_helper#30

Closed

unixfox and others added 10 commits November 16, 2024 22:36

add support for invidious companion

3dff7a7

redirect latest_version and dash manifest to invidious companion

73c84ba

fix Shadowing outer local variable response

1954463

fixing condition for Content-Security-Policy

c612423

throw error if inv_sig_helper and invidious_companion used same time

2cc204a

Use sample instead of Random.rand

1c9f5b0

Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>

Remove debug puts functions

27b24f5

Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>

modify the description for config.example.yaml about invidious companion

409df4c

move config checks for invidious companion

ff3305d

separate invidious_companion logic + better config.yaml config

1aa154b

unixfox force-pushed the invidious-companion branch from 97ae26c to 1aa154b Compare November 16, 2024 21:36

fixing "end" misplacement

9f84612

unixfox added 5 commits November 16, 2024 23:00

fix linting + use .empty?

b51770d

crystal handle decompression already by itself

bb2e3b2

fix download function when invidious companion used

734e725

fix linting

1f51edd

invidious companion always used so always add CSP and redirect latest…

7a070fa

…_version

unixfox mentioned this pull request Nov 18, 2024

jobs.youtube_session: "Got response but no post-process functions" iv-org/invidious-companion#12

Open

SamantazFox requested changes Nov 19, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add invidious companion support #4985

Add invidious companion support #4985

unixfox commented Oct 7, 2024 •

edited

Loading

SamantazFox Nov 5, 2024

unixfox Nov 5, 2024 •

edited

Loading

SamantazFox Nov 5, 2024

unixfox Nov 6, 2024 •

edited

Loading

SamantazFox Nov 7, 2024 •

edited

Loading

unixfox Nov 7, 2024 •

edited

Loading

SamantazFox Nov 8, 2024

unixfox Nov 17, 2024 •

edited

Loading

unixfox commented Nov 5, 2024

SamantazFox Nov 7, 2024 •

edited

Loading

SamantazFox Nov 19, 2024

SamantazFox Nov 19, 2024

unixfox Nov 19, 2024 •

edited

Loading

SamantazFox Nov 19, 2024

SamantazFox Nov 19, 2024 •

edited

Loading

SamantazFox Nov 19, 2024

unixfox Nov 19, 2024

SamantazFox Nov 19, 2024

unixfox Nov 19, 2024

SamantazFox Nov 19, 2024

SamantazFox Nov 19, 2024

unixfox Nov 19, 2024

SamantazFox Nov 19, 2024

SamantazFox Nov 19, 2024

		elsif itag = download_widget["itag"]?.try &.as_i
		itag = itag.to_s

	return env.redirect "#{video.invidious_companion.not_nil!["baseUrl"].as_s}/latest_version?id=#{video_id}&itag=#{itag}&local=true"
	return env.redirect "#{video.invidious_companion.not_nil!["baseUrl"].as_s}/latest_version?#{env.params.query}"

	"Authorization" => "Bearer " + CONFIG.invidious_companion_key,
	"Authorization" => "Bearer #{CONFIG.invidious_companion_key}",

Add invidious companion support #4985

Are you sure you want to change the base?

Add invidious companion support #4985

Conversation

unixfox commented Oct 7, 2024 • edited Loading

Description

What does this PR do?

What does invidious companion do

Incompatibilities

How to try?

Fixes

Related to

Choose a reason for hiding this comment

unixfox Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unixfox Nov 6, 2024 • edited Loading

Choose a reason for hiding this comment

SamantazFox Nov 7, 2024 • edited Loading

Choose a reason for hiding this comment

unixfox Nov 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unixfox Nov 17, 2024 • edited Loading

Choose a reason for hiding this comment

unixfox commented Nov 5, 2024

SamantazFox Nov 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unixfox Nov 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SamantazFox Nov 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unixfox commented Oct 7, 2024 •

edited

Loading

unixfox Nov 5, 2024 •

edited

Loading

unixfox Nov 6, 2024 •

edited

Loading

SamantazFox Nov 7, 2024 •

edited

Loading

unixfox Nov 7, 2024 •

edited

Loading

unixfox Nov 17, 2024 •

edited

Loading

SamantazFox Nov 7, 2024 •

edited

Loading

unixfox Nov 19, 2024 •

edited

Loading

SamantazFox Nov 19, 2024 •

edited

Loading