feat: disable proxy

The main use case is for when I'm running a local instance of the OMSS provider within my local network or Raspberry Pi, then there would be no need for the proxy since the IP is still the same.

It would be nice if there was a global environment flag or configuration to disable the proxy behaviour, since it's added overhead that might not be necessary for all situations.

It's also useful because I would like to use the spec to write some providers that can work with Stremio (awesome, that that's already natively supported), but also Nuvio providers, which are basically self-contained singular javascript files that can be executed by the local device (using QuickJS) without needing to host or proxy it on a server (severely reducing the barrier to entry for using providers). An example compiled provider is available here on the main branch.

I already have a working version that compiles the provider into a single script (and unraveling the proxy URL from the source and subtitles), I can contribute it back into a public fork in due course, in case it's something that's useful - but that's not the main focus of this PR.

Hey there.

Thank you for your interest and your suggestions.
To be honest I would split the two requests into two separate issues (please do). However, I will respond to both now.

Proxy:

The main use case is for when I'm running a local instance of the OMSS provider within my local network or Raspberry Pi, then there would be no need for the proxy since the IP is still the same.
It would be nice if there was a global environment flag or configuration to disable the proxy behaviour, since it's added overhead that might not be necessary for all situations.

The proxy does not exist for "changing the IP" (cause how you pointed out correctly, it does not). The proxy is required that you can play the files. Many streams/files check "from where" are you playing it (Referrer / Origin header). To spoof that/set custom headers, you need a proxy between, cause otherwise you would get CORS issues. In other words, without a proxy, there is a high risk, you won't be able to use most of the streams (note: of course not all files check for the "correct" headers, but most of them do). [you probably know this already, but for the people later]

Nuvio providers

It's also useful because I would like to use the ~~spec~~ edit: framework to write some providers that can work with Stremio (awesome, that that's already natively supported), but also Nuvio providers, which are basically self-contained singular javascript files that can be executed by the local device (using QuickJS) without needing to host or proxy it on a server (severely reducing the barrier to entry for using providers). An example compiled provider is available here on the main branch.
I already have a working version that compiles the provider into a single script (and unraveling the proxy URL from the source and subtitles), I can contribute it back into a public fork in due course, in case it's something that's useful - but that's not the main focus of this PR.

Hmmm.... okay interesting. I mean I also use Nuvio but I got one question. Where/when do these js files get injected into the app? cause to my knowledge nuvio is just another stremio client right? and like you pointed out, we already support that.

I like the concept of running the scraper locally without a proxy, but.... well i guess we could add a build step/script that "compiles" the ts into the quickjs files in the dist folder.... If you could share your script that would be nice. The only thing that I worry, is that nuvio providers is not client agnostic. you have to use the nuvio app [because of the predefined dependencies].... That might be another issue, cause that limits the scraping options. To be honest I am not sure. More thoughts are welcome.

In other words, without a proxy, there is a high risk, you won't be able to use most of the streams (note: of course not all files check for the "correct" headers, but most of them do).

That makes sense, but I think scenarios where the client is capable of adding the headers themselves (such as Nuvio and Stremio) are valid use cases for when it'd be better to have the proxy part off too.

I think it's probably fine to have a helper function to un-ravel the proxy source, and pass the headers back to the user based off a configuration/environment - so it can be used on the dev's discretion or something, but some thought will need to be had on a way to do this without messing with the API too much.

Hmmm.... okay interesting. I mean I also use Nuvio but I got one question. Where/when do these js files get injected into the app? cause to my knowledge nuvio is just another stremio client right? and like you pointed out, we already support that.

There's a section in the app for "Plugins", and that's where you'd point it to the repository containing your local providers.

"Addons" is what it uses for Stremio.

I like the concept of running the scraper locally without a proxy, but.... well i guess we could add a build step/script that "compiles" the ts into the quickjs files in the dist folder.... If you could share your script that would be nice.

Sure, will clean up the code and update the issue with a link to the https://github.com/cinepro-org/core fork I have locally.

Also, one thing I noticed was that the health service within the main server can't be made to recognize newer endpoints declared by the new server. It'd be nice if there was a function to register/alter the list of endpoints shown.

The only thing that I worry, is that nuvio providers is not client agnostic. you have to use the nuvio app [because of the predefined dependencies].... That might be another issue, cause that limits the scraping options. To be honest I am not sure. More thoughts are welcome.

I agree that Nuvio is definitely a lot more limited in terms of what it's capable of doing (the biggest limitation I've found so far is that for certain providers like peachify, it might not have access to newer nodejs modules like crypto or algorithms like AES-GCM etc).

So will just not support them for those providers, or if the provider developer strongly wants to support it in Nuvio, then they'll use an external endpoint they own or a public one like https://github.com/smy778/EncDecEndpoints or something to do the nodejs decoding. Every other provider seems to work fine otherwise.

But I think that's an acceptable trade-off that users choosing to use a local scraper in a tiny VM should be willing to live with (at least until Nuvio decides to run an entire nodejs-equivalent environment directly themselves).

There's a section in the app for "Plugins", and that's where you'd point it to the repository containing your local providers.
"Addons" is what it uses for Stremio.

OOOkkayy.. now everything makes sense. I will get back to you about the Nuvio Plugin system in #3 to keep the conversation clean.

note: When talking about "plugin" nuvio plugins are meant.

That makes sense, but I think scenarios where the client is capable of adding the headers themselves (such as Nuvio and Stremio) are valid use cases for when it'd be better to have the proxy part off too.
I think it's probably fine to have a helper function to un-ravel the proxy source, and pass the headers back to the user based off a configuration/environment - so it can be used on the dev's discretion or something, but some thought will need to be had on a way to do this without messing with the API too much.

Okay..... Hear me out. Since we want to get the proxy out of the way when using it for Nuvio/Stremio, we can do the following changes:

When the DISABLE_PROXY env is true, the omss framework will not start the proxy.
In addition, if the proxy is disabled AND enableNativeAddon is true, the stremio responses will not include the proxy links, but rather send back the headers in the proxyHeaders object. Additionally, the stream.behaviorHints.notWebReady will be set to true.

Is this how you've imagined it? Suggestions? Let me know, so I can get started with implementing

That makes sense, but I think scenarios where the client is capable of adding the headers themselves (such as Nuvio and Stremio) are valid use cases for when it'd be better to have the proxy part off too.
I think it's probably fine to have a helper function to un-ravel the proxy source, and pass the headers back to the user based off a configuration/environment - so it can be used on the dev's discretion or something, but some thought will need to be had on a way to do this without messing with the API too much.

Okay..... Hear me out. Since we want to get the proxy out of the way when using it for Nuvio/Stremio, we can do the following changes:

When the DISABLE_PROXY env is true, the omss framework will not start the proxy.
In addition, if the proxy is disabled AND enableNativeAddon is true, the stremio responses will not include the proxy links, but rather send back the headers in the proxyHeaders object. Additionally, the stream.behaviorHints.notWebReady will be set to true.

Is this how you've imagined it? Suggestions? Let me know, so I can get started with implementing

How about making it a query parameter as well, and also compatible for non-Stremio use cases?

I'm building my own app to streaming, and I don't need the proxy because it's an electron app. It would be easier if you also sent down the headers with the response, and allowed us to make the request.

@anochj

Hello @anochj

Hmmm. I definitely see your point.

The fix discussed/suggested above would only apply to the stremio endpoint.

To change the default behaviour/adding query params would require a change in the OMSS spec.

I will definitely take this into consideration for v1.1 (ETA: 1-2 weeks). (Maybe a ?platform=(web|native) param)

Theoretically you can unwrap the proxy link and extract the original url and headers.

Hello @anochj

Hmmm. I definitely see your point.

The fix discussed/suggested above would only apply to the stremio endpoint.

To change the default behaviour/adding query params would require a change in the OMSS spec.

I will definitely take this into consideration for v1.1 (ETA: 1-2 weeks). (Maybe a ?platform=(web|native) param)

Theoretically you can unwrap the proxy link and extract the original url and headers.

Theoretically, you could, but it's still kind of a hassle. Anyways, not something that's urgent.

I've opened a RFC to address this: omss-spec/omss-spec#2

@An0n-00

Well my main account @An0n-00 got banned so the issue opened before is also gone. It will take some time for github to open it again. all the issues/comments made are lost.

@autovalue

@autovalue @anochj I've opened omss-spec/omss-spec#3

The changes discussed here and addressed in OMSS v1.1 will be implemented here. This repo will be archived.

Navigation Menu

Repository navigation

feat: disable proxy #2

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

feat: disable proxy #2

Description

Activity

An0n-01 commented on May 19, 2026

autovalue commented on May 21, 2026

An0n-01 commented on May 21, 2026

An0n-01 commented on May 21, 2026

anochj commented on May 25, 2026

An0n-00 commented on May 25, 2026

anochj commented on May 25, 2026

An0n-00 commented on May 26, 2026

An0n-01 commented on May 27, 2026

An0n-01 commented on Jun 8, 2026

An0n-01 commented on Jun 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions