Instances not respecting the new rules

[TheFrenchGhosty]

This is an issue meant to keep track of instances currently in the instances list that aren't respecting the new rules: https://github.com/iv-org/documentation/blob/master/Invidious-Instances.md#rules-to-have-your-instance-in-this-list

https://yewtu.be/ : Rule 11 @unixfox

https://ytb.trom.tf : Rule 3, 11 @tio-trom

Instances have until the end of the month to fix this issue, otherwise they will be removed from the list.

Instances that were removed in b98707a :

https://ytprivate.com : Rule 2, 12 @ytprivatecom - This is your last warning about keeping your instance up to date. Next time we won't add it back to the instances list.

https://yt.didw.to : Rule 2 @didw-to

[unixfox]

ytb.trom.tf source code is already listed in https://github.com/iv-org/documentation/blob/master/Invidious-Instances.md#list-of-public-invidious-instances-sorted-from-oldest-to-newest

Is that enough?

[TheFrenchGhosty]

@unixfox

ytb.trom.tf source code is already listed in https://github.com/iv-org/documentation/blob/master/Invidious-Instances.md#list-of-public-invidious-instances-sorted-from-oldest-to-newest

Is that enough?

It's currently not respecting this point: "MUST contain a link to both the modified and original source code of Invidious, ideally in the footer.", it doesn't link to the modified source code in the instance itself.

[tio-trom]

Ok will do that this month.

[unixfox]

@unixfox

ytb.trom.tf source code is already listed in master/Invidious-Instances.md#list-of-public-invidious-instances-sorted-from-oldest-to-newest
Is that enough?

It's currently not respecting this point: "MUST contain a link to both the modified and original source code of Invidious, ideally in the footer.", it doesn't link to the modified source code in the instance itself.

The current Invidious code doesn't allow for an easy and properly way to add the source code in the footer. I don't think it's a good idea to enforce this rule, we should wait until we implement a system that allow to specify a link to the source code.

For instance Searx allow specifying the URL to the source code with just an environment variable, this will change the URL of the "Source code" link at the footer of the page.

Patching means that if something is changed in the Invidious code it will require some manual intervention in order to fix the patch. If the code for the footer of Invidious get changed, then the patch is broken until the maintainer fix it. I've no desire to spend some time each time the footer code get changed.

In conclusion, in iv-org/invidious#2215 we should add the ability to modify the source code link and then we can start enforcing the rule.

[tio-trom]

Very good point @unifox !

[TheFrenchGhosty]

The current Invidious code doesn't allow for an easy and properly way to add the source code in the footer. I don't think it's a good idea to enforce this rule, we should wait until we implement a system that allow to specify a link to the source code

If an instance owner can modify the code to add what they want, they can modify the code to link to their changes. If they can't, well, they can just run master.

We should add a way for instances owners to add a link in an easier way, but currently, it's good enough.

[unixfox]

The current Invidious code doesn't allow for an easy and properly way to add the source code in the footer. I don't think it's a good idea to enforce this rule, we should wait until we implement a system that allow to specify a link to the source code

If an instance owner can modify the code to add what they want, they can modify the code to link to their changes. If they can't, well, they can just run master.

I don't think you ever maintained patches, if a part of the original code that a patch uses change then the patch is broken, and it requires a manual intervention.

Each patch that I wrote is specially crafted in order to touch as less current code as possible, and thus I hardly ever need to fix any patch. Adding a new link to the footer is asking for manual intervention every time the footer code get updated.

[TheFrenchGhosty]

I don't think you ever maintained patches, if a part of the original code that a patch uses change then the patch is broken, and it requires a manual intervention.

Each patch that I wrote is specially crafted in order to touch as less current code as possible, and thus I hardly ever need to fix any patch. Adding a link to the footer is asking for manual intervention every time the footer code get updated.

The footer is rarely updated.

Also, I mean, I'm sorry to say that, and I hope you don't take it the wrong way: but it's not really our problem, instances owner are responsible for their instances, and as I said: "If they can't [maintain their changes], well, they can just run master."

[unixfox]

Also, I mean, I'm sorry to say that, and I hope you don't take it the wrong way: but it's not really our problem, instances owner are responsible for their instances, and as I said: "If they can't [maintain their changes], well, they can just run master."

It's not really my problem either to add a source code link when it's already stipulated in the instances list :).

I'm perfectly capable of maintaining any changes that I deliberately made the choice to add, but what I don't want is to frequently spend time on things that I didn't make the choice to change. I'm fine with adding once things that I didn't initially want to change, but I don't want these things to bother me over time.

The time lost could have been better spent on improving the usability of my instance or invidious as a whole.

I'm going to add a patch that link to the source code of my instance in the footer but as soon as my patch break I'm removing it even if this break the rules. I've no desire to lose some of my free time when I'm already providing a service for anyone for free.

[TheFrenchGhosty]

It's not really my problem either to add a source code link when it's already stipulated in the instances list :).

Well it is if you want your instance to be in the instances list.

I'm going to add a patch that link to the source code of my instance in the footer but as soon as my patch break I'm removing it even if this break the rules. I've no desire to lose some of my free time when I'm already providing a service for anyone for free.

We'll then have to remove your instance from the instances list, we won't make exceptions, even if you are in the Invidious team.

[unixfox]

It's not really my problem either to add a source code link when it's already stipulated in the instances list :).

Well it is if you want your instance to be in the instances list.

Legally an instance that publish its source code somewhere easily accessible from the public is already compliant with AGPL (cf. the instance list markdown file). Adding that to the footer of the instance is just a bonus.

I'm going to add a patch that link to the source code of my instance in the footer but as soon as my patch break I'm removing it even if this break the rules. I've no desire to lose some of my free time when I'm already providing a service for anyone for free.

We'll then have to remove your instance from the instances list, we won't make exceptions, even if you are in the Invidious team.

That's fine and I would then leave the project altogether because it wouldn't meet my main criteria anymore of why I work on open source projects.
I started working on open source projects because I liked the idea to do whatever my imagination want me to do, free from any rules that refrain the innovation.
Once this is not the case anymore I just move on.

[syeopite]

I started working on open source projects because I liked the idea to do whatever my imagination want me to do, free from any rules that refrain the innovation.
Once this is not the case anymore I just move on

I'm sorry, but doesn't this mean Invidious has never meet your criteria? We've never allowed you to do "whatever my imagination want me to do", the instance list always had rules pertaining to analytics and MITM/DDoS protection. Not to mention the AGPL restricting it further with the source code disclosure and notice clause.

I really don't see the point of this argument here. Since, all we're doing is barring an instance from being placed on the official list. If you wish to host an instance that doesn't follow any of the above rules, you're free to do so.

Legally an instance that publish its source code somewhere easily accessible from the public is already compliant with AGPL (cf. the instance list markdown file). Adding that to the footer of the instance is just a bonus.

No. Not exactly. The AGPL requires the work itself to also have prominent notices that it's modified.

    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.

    b) The work must carry prominent notices stating that it is
    released under this License and any conditions added under section
    7.  This requirement modifies the requirement in section 4 to
    "keep intact all notices".

So at minimum, even if your instance isn't on the official list, the work itself still needs to be clearly marked as modified if it is modified.

[TheFrenchGhosty]

I completely agree with @syeopite

The AGPL requires the work itself to also have prominent notices that it's modified

Currently yewtube is breaking this. I haven't removed from the instance list before because it's your ( @unixfox ) instance, but it has been in violation of the AGPL for months.

We already made an exception for it for months, I asked you ( @unixfox ) multiples times to fix this, those rules have been almost all written months ago too. Enforcing them was obviously the next step.

[tirz]

Hi, I am the maintainer of http://kbjggqkzv65ivcqj6bumvp337z6264huv5kpkwuv6gu5yjiskvan7fad.onion/ o/

I completely agreed with @unixfox.

He did not say he wanted to hide the fact that his source code is modified, he just said that it is currently hard to share the link of the modified project.
Even if we can do better, having it wrote in the public instance list in already clear.
But if Invidious asks for the developer to also put the link in the footer... Then Invidious must provide a way to add this link to the footer.
Currently, I just see this rule as a dick move to remove all forks from the public list.

@TheFrenchGhosty

The footer is rarely updated.

Rarely means his patch will break one day or another.
Hard coding the link here is still not a clean and stable way to do it.

But some others rules disturbed me.

3. Instances MUST have statistics (/api/v1/stats) enabled (statistics_enabled:true in the configuration file).

I have a no-log policy and I do not want to give up that.
I even run Invidious inside a Podman with "--log-driver none" so I cannot see the intensives Invidious logs on my console or in my systemd.logs.
What you are asking now is to release the numbers of users / active users by instances and maybe more if this stupid and now mandatory route get updated in the future.
Are you forcing all the public's instances to log their users just to check in the "/api/v1/stats" if the instance was recently updated ?
Can we add an exception to the .onion ?

8. Instances using any type of anti-bot protection MUST be marked as such.

I use a personal reverse proxy coded in Rust (it is like Morty).
I planned to share the source code of the reverse proxy but it is not ready yet.
Anyway, why should I advertise my users about how my infrastructure works and how I protect myself ?
"any type" is too strong. What about "intrusive type" ? If the anti-bot add a cookie, or some JavaScript, etc...
My anti-bot is totally transparent and I do not see how to explain that with a long paragraph.
Also, where should I put this long paragraph ?
And are iptables filters denied by Invidious ?

10. Any system whose goal is to modify the content served to the user (HTTP server rewrite, scripts, etc...) is considered the same as modifying the source code.

What do you mean by "HTTP server rewrite" ?
I use Caddy as a reverse proxy and I check if some headers are present in the response of the server.
If they are not, I add them : "X-Xss-Protection: 1;mode=block" or "Permissions-Policy: interest-cohort=()", etc.
Yes, Invidious already does this, but not all the servers that I am hosting.
But are you saying that it is denied to configure Invidious if the config is not available in config.yml ?
Should I modify my global config just for Invidious ?
What if I put nginx ? The default config adds a header "served by nginx".
Is it considered as an "HTTP server rewrite" or is it tolerated ?