Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PATCH] Add support for listing Tor/onion and i2p invidious instances. #32

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cxtal
Copy link

@cxtal cxtal commented Dec 8, 2023

Hello! I made a few changes to the redirector to permit Tor/onion and I2P links to be listed as part of the same table. Ultimately, this was up to everyone's Feng-Shui; whether there should be a separate table for darknet, whether the table would be after the clearnet one, whether it should be to the right, etc, but I decided that darknet links are just as important and should just be part of the entire corpus of links.

There is one problem, but more like a debate. All darknet links, that includes both Tor/onion and I2P appear with health being "unknown" and I am not sure whether this is from the API itself at api.invidious.io or whether people simply hide their /stats for darknet addresses. In any case, I do not see why health reports could not be generated for darknet invidious instances as well and at the very least it would not be deanonimizing to the end-user (and I doubt it would to the server either). That being said, and for further work, either the health check return entry.health > 0 can be removed thereby making invidious list everything or either api.invidious.io or the individual instances should enable the /stats link to check for health. There is not reason why Tor/onion or I2P services could not be ranked along the rest and it's just the transport that differs.

As a demo, please see the following website:

that shows the result of this commit.

One more comment is that api.invidious.io reports all I2P address names with the "http" prefix whereas both onion and clearnet addresses have the starting "http", respectively "https" prefix stripped from the returned name parameter. Not sure why and it is ultimately irrelevant to this pull request but just mentioning it.

Please apply if useful.

@unixfox
Copy link
Member

unixfox commented Dec 8, 2023

hello, to be fair I think non clear net instances should be separated from clear net ones.

Like in another section below the main section.

This might confuse people in why there are "other" protocols than "HTTPS" instances.

@cxtal
Copy link
Author

cxtal commented Dec 8, 2023

Initially the idea was to place it after (and then next to it) but that was not done because then it would take a large amount of time to scroll down all the way (then the "next to the existing table" was dropped, because it would require the browser to have a wider resolution) to see the darknet instances. Even so, semantically, there should be no difference between darknet or clearnet instances, given that the table measures them all in terms of health and that it might so happen that a darknet instance is better than a clearnet one.

Of course, this is "design" so it is fairly relative as to what you want your own software to look like. If you want to just fork the table, then I am okay with it, but just noting the above. I also do not think Invidious is for end-users and it requires some understanding as to what is going on, especially when you redirect to multiple instances such that some knowledge of Tor / I2P darknet should be required. Even if they do not know, they can look it up or ask around. Clearly, both .onion and .i2p addresses are outlandish enough to make it clear to anyone they are not the usual addresses one would be used to.

Ultimately, it is up to you, but it definitely would be nice to list darknet addresses for an extra surplus of privacy, which is what Invidious is to me with the design being subjective.

@unixfox
Copy link
Member

unixfox commented Dec 8, 2023

given that the table measures them all in terms of health and that it might so happen that a darknet instance is better than a clearnet one.

health is not tracked for darknet instances. you can see it on your demo website. it say "unknown".

I also do not think Invidious is for end-users and it requires some understanding as to what is going on

we definitively have non-technical/user savvy users in the community. that's why I'm making the point to make two section: clear net instances and darknet instances.

this way advanced users just have to scroll in order to find the darknet instances. or if you do not like to scroll then we could have a "tab" functionality similar to searxng's instances list instances page: https://searx.space

@cxtal
Copy link
Author

cxtal commented Dec 8, 2023

health is not tracked for darknet instances. you can see it on your demo website. it say "unknown".

It is mentioned in the PR as something that should be considered given that Invidious instance health data is not a de-anonymizing feature. Might be something worth doing because ultimately there is nothing magical about Tor/onion or I2P instances. Also, they already deanonimize given that they declare their country of origin so I am not sure what harm some some extra stats like last restart time or uptime could do.

or if you do not like to scroll then we could have a "tab" functionality

this was another variant considered, to have a button and switch :) but finally did not go that way because it requires an extra click

Again, I have nothing against any other variant. To be fair, I just want the Tor/I2P addresses listed because I use them extensively and given that Invidious can be hosted through Tor/I2P, it's all the better. Initially I used to browse YouTube with Tor, but after the Google takeover way back, it is now impossible to browse.

@cxtal
Copy link
Author

cxtal commented Dec 8, 2023

Also considered a variant where window.url is read, and if it is determined that the redirector is running under an onion address, then display only Tor Invidious instances (same for I2P). Then again, if you browse through Tor, it does not mean you should / can't switch over to I2P directly from the redirector so dropped that variant as well. :)

@syeopite
Copy link
Member

syeopite commented Dec 8, 2023

There is an old PR to add health and instance stats for tor instances iv-org/instances-api#29

@cxtal
Copy link
Author

cxtal commented Dec 8, 2023

There is an old PR to add health and instance stats for tor instances iv-org/instances-api#29

I like this, but it's up to whomever is hosting the current public API, if they can run Tor/I2P on the same machine or if it exceeds resources (I2P might). Stuff like tor2web that is mentioned by @unixfox in the comments works too and there is an I2P equivalent https://i2phides.me/ (for example https://zzlsbhhfvwg3oh36tcvx4r7n6jrw7zibvyvfxqlodcwn3mfrvzuq.b32.i2phides.me/ for one of the instances).

The main point I think is that there is no reason to just lose out on the potential traffic distribution if people can use Tor / I2P. Just now I loaded up a video through one of the public Tor instances and I did not really see any speed difference from a clearnet one. So like, why not, the more, the merrier.

Also with Tor/I2P you get a free domain/IP so you could potentially host dozen of instances with Kubernetes at zero cost except maintenance which is not something you can do with clearnet where you need a domain and IP that is bound to a DNS registry / ISP .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants