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 ?

[TheFrenchGhosty]

@tirz (sorry the message is a bit messy but I answered most of your questions)

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.

Hard coding the link here is still not a clean and stable way to do it.

Yes, this is something that will be done soon, however for now source modification is needed.

Currently, I just see this rule as a dick move to remove all forks from the public list.

It's a move to remove all forks that don't respect the AGPL.

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 ?

/api/v1/stats contain a really small amount of details, see for example snopyta's instance: https://invidious.snopyta.org/api/v1/stats it doesn't requires anything other than to be enabled.

Can we add an exception to the .onion ?

Since it's only for api.invidious.io and api.invidious.io doesn't yet support onion, yes, but this will change in the future.

Anyway, why should I advertise my users about how my infrastructure works and how I protect myself ?

It's all about transparency.

"any type" is too strong. What about "intrusive type" ? If the anti-bot add a cookie, or some JavaScript, etc...

This isn't a bad idea yeah, we basically only need to have them listed in case they add/run cookies/JavaScript on clients (most do), but I guess those not doing that, are "okay", it's too be discussed yes, feel free to open a new issue about it.

Also, where should I put this long paragraph ?

In the instances list, like we always did.

What do you mean by "HTTP server rewrite" ?

Path rewritten to link to somewhere, stuff added (without a source modification) like analytics...

Headers are fine.

But are you saying that it is denied to configure Invidious if the config is not available in config.yml ?

If it's to rewrite an URL, it's considered a source code modification, yes, but for more "backend" stuff (headers, robots.txt override...) it's allowed.

[tio-trom]

I'd like that you guys and girls don't forget that, very likely, the ones behind invidious instances are doing it in their free time and to help clean the internet a bit. Probably all of our intentions are good. So try not to make it too difficult for us to maintain these instances in order to get them on the official list, else you will lose many of us.

Reading through the list of requirements it seems quite a lot and I am doubtful any of you can manage to enforce these, especially when you allow advertisement but under a curtain of rules. Is the master invidious set up exactly the way you are enforcing the rules? Meaning if I were to clean install form the master branch, would I classify for the official list?

We provide many services via trom.tf and we are on many official lists, but I never seen such an aggressive enforcing of rules anywhere so far. And a bit of unfriendliness that I feel (maybe is just me). I have to say I always feel under pressure with invidious since you add too many rules to be on the official list that I wanted these days to tell you to remove ytb.trom.tf. Despite the fact that all we do is install the from the master branch and only do some CSS changes. You wanted me to mention the changes in the invidious list (and I did), then to keep the footer (why is that a requirement?) - I did that too -, and now to add the changes in the footer... I may do that, but you may lose me eventually if you add more and more such rules, considering all we did so far with our instance is to design it (add our custom theme basically). You may add a rule saying that instances that look too different should be removed, so no custom theming allowed. I won't be surprised. That's my feeling right now.

Anyways. Just keep it more calm and relaxed, we are here to help out.

I totally get that this is just your list and it is great that you want quality instances. But try not to lose contributors or instance admins by becoming too strict. Licenses are not working anyways, they always get "violated". It is an endless and bottomless war.

[SamantazFox]

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.

Yep, I'm working on that, so you'll just have to put the URL in your config and not think about it :)

1. 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 ?

the API has always been enforced, but it was never clearly marked.
Edit: it's has been enforced for something like a year now. The only ones not being enforced for now are the .onion for a technical reason (IIRC, that's because the instance-api webpage can't use TOR, but I may be wrong)

The content of the statistics is (currently) limited to the registered users count.

In the future, I'd like to have server side stats so we can know, without tracking the users, how many times an endpoint is acessed and how often the server is having memory issues. The end goal would be to have realistical instance data to track memory leaks down (you're probably already aware that we have a big issue on that).

NB: that's something I (samantaz) would like, that doesn't reflect the decision of the team!

"any type" is too strong. What about "intrusive type" ? If the anti-bot add a cookie, or some JavaScript, etc...

I agree, we should probably limit that to "intrusive" ones only.

What do you mean by "HTTP server rewrite" ?

We may reword that, yes. That's intended for people who'd want to bypass the AGPL saying "no, I haven't touched the code" and rewrite the HTML on the fly.

[SamantazFox]

I'd like that you guys and girls don't forget that, very likely, the ones behind invidious instances are doing it in their free time and to help clean the internet a bit. Probably all of our intentions are good. So try not to make it too difficult for us to maintain these instances in order to get them on the official list, else you will lose many of us.

yeah, we are aware. That's why I opened #149, in order to discuss the rules with you, the maintainers. I've seen that there has been quite a lot of friction over that rules rewrite...

[tio-trom]

I'd like to ask you to remove ytb.trom.tf from the list, for now, since it is not working properly anyways. I tried and tried to fix it. We use it via yunohost and I see they are working these days to fix the package. I would like that the official invidious lists is made out of instances that work properly, so for now you can remove our instance. As soon as it will work, I will look over the requirements, do them, and submit our instance to the official list. It is a shame since we use invidious internally a lot for our project, and we'd like to provide a good working instance. I hope to be back soon with a properly working instance and submit it again.

Thanks!

[ytprivatecom]

YTPrivate is updated, sorry, had surgery.

[didw-to]

yt.didw.to has been updatet.

[syeopite]

Apologies for the late reply everyone

@ytprivatecom

YTPrivate is updated, sorry, had surgery.

Oh, hope you're feeling better now! But friendly reminder, it looks like your certificate has expired. Once you renew it, I'd go ahead and give your instance a proper re-review.

@didw-to

yt.didw.to has been updatet.

Thanks! Added it back onto the list. Please make sure your instance isn't outdated again.

[TheFrenchGhosty]

@ytprivatecom We haven't had any news from you in more than 2 months, and your certificate is still outdated... I hope you're okay...

@tio-trom Any news?

@didw-to Your instance hasn't been updated since your last message on October 26... please keep it updated.

[TheFrenchGhosty]

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

Now respects all the rules, thank you!

Since all other instances now respects the rules, I am closing this issue.

[tio-trom]

@tio-trom Any news?

Sorry. We are too busy to do it all by-the-book and add all of the changes to the footer and all that. Plus, we still cannot make our instance work well. It crashes many times every day and needs manual rebooting....so better not have it on the list.

[TheFrenchGhosty]

@tio-trom Other than making the footer visible, we added a config option to link to your modified source, so it should be easy.

Plus, we still cannot make our instance work well. It crashes many times every day and needs manual rebooting....so better not have it on the list.

That's all invidious instances, restart hourly and it will work perfectly.

If you need help with anything, feel free to ask

[tio-trom]

Sounds good! I will let our instance admin know and try to do all of those. Thanks!