Many of the Piped instance listed are no longer active with some being entirely different sites

[Darin755]

Official Instance

• [ X] The bug is reproducible on the official hosted instance, or is API-related.

Describe the bug

Instances with a Cloudflare error page

https://pipedapi.tokhmi.xyz/

https://pipedapi.moomoo.me/

https://api-piped.mha.fi/

https://pipedapi.pfcd.me/

https://pipedapi.coldforge.xyz/

Instances with other issues:

https://pipedapi.syncpundit.io/ (Shows "welcome to nginx")

https://piped-api.garudalinux.org (DNS not resolving to an IP)

https://pipedapi.rivo.lol/ (does not load)

https://ytapi.dc09.ru/ (DNS returns a bad IP)

https://pipedapi.colinslegacy.com/ (DNS not resolving to an IP)

https://piped-api.cfe.re (DNS not resolving)

https://pipedapi.nosebs.ru (DNS not resolving)

https://pa.mint.lgbt/ (DNS not resolving)

https://piped-api.privacy.com.de/ (Secure connection fails)

https://pipedapi.us.projectsegfau.lt/ (bad gateway)

https://watchapi.whatever.social/ (secure connection fails)

https://pipedapi.qdi.fi/ (DNS not resolving)

https://piped-api.hostux.net/ (Fails to load)

https://pdapi.vern.cc/ (Redirects back to vern home page)

https://pipedapi.osphost.fi/ (404)

https://pipedapi.simpleprivacy.fr/ (redirects to simpleprivacy.fr)

https://api.watch.pluto.lat/ (DNS not resolving)

https://pipedapi.owo.si/ (Bad gateway)

https://api.piped.minionflo.net/ (Returns hello world page)

https://pipedapi.nezumi.party/ (DNS does not resolve)

https://pipedapi.andreafortuna.org (DNS does not resolve)

Instances showing bad or strange behavior

https://yapi.vyper.me/ (redirects a bunch before being blocked by ublock origin)

https://api.looleh.xyz/ (Shows a generic looking page that says "no sponsors")

https://pa.il.ax/ (Redirects to a page blocked by ublock origin)

https://pipedapi.palveluntarjoaja.eu/ (Redirects)

https://piped-backend.seitan-ayoub.lol/ (Shows "no sponsors")

To Reproduce

1. Try to visit on of the sites listed

Expected behavior

I was looking if I could successfully access the Piped main page. (I did not try to play a video) I am based in the US so every one of these was tested from a US IP address.

Logs/Errors

See above

Browser, and OS with Version.

Firefox 129.0 on Linux

Additional context

I would not recommend removing these all at once. What I would suggest is a "scream test." Basically what you would do is you would remove 3-4 links at a time and then wait to see if anyone complains. If they do you can re add the link. This will take a lot of time but you could do it once a month. I would be willing to facilitate this but the wiki is not a public repo.

Please prioritize the sites that are redirecting to strange pages. I do not know if they are harmful but if Ublock origin blocked them it usually is not a good sign.

[Bnyro]

The instances list is now located at https://github.com/TeamPiped/documentation/blob/main/content/docs/public-instances/index.md, please create a pull request with the suggested removals (only the version obvious faulty ones for now please), and we'll see if there will be any complaints.

[Darin755]

Would it be possible to add an official policy for removing instances? Right now there is quite a lot of grey area as to what instances are subject for removal. Maybe some sort of uptime requirement could be added. Maybe if an instance is down for more than 30 days continuously it should be removed. This could be automated with a bot that checks if an instance is up every so often. Having a bot would also allow for outage notices.

[Bnyro]

Would it be possible to add an official policy for removing instances? Right now there is quite a lot of grey area as to what instances are subject for removal. Maybe some sort of uptime requirement could be added. Maybe if an instance is down for more than 30 days continuously it should be removed.

I agree, that seems like a good idea. We can add that to https://github.com/TeamPiped/documentation/blob/main/README.md, 30 days seems reasonable.

This could be automated with a bot that checks if an instance is up every so often. Having a bot would also allow for outage notices.

https://piped-instances.kavin.rocks already keeps track of the uptime of the instances, it would probably make sense to extend it to an API path that returns all the instances without any uptime in the last 30 days. Writing a bot for that is probably an overkill, it's simple enough to check this by hand every now and then.

[Darin755]

Would it be possible to add an official policy for removing instances? Right now there is quite a lot of grey area as to what instances are subject for removal. Maybe some sort of uptime requirement could be added. Maybe if an instance is down for more than 30 days continuously it should be removed.

I agree, that seems like a good idea. We can add that to https://github.com/TeamPiped/documentation/blob/main/README.md, 30 days seems reasonable.

This could be automated with a bot that checks if an instance is up every so often. Having a bot would also allow for outage notices.

https://piped-instances.kavin.rocks already keeps track of the uptime of the instances, it would probably make sense to extend it to an API path that returns all the instances without any uptime in the last 30 days. Writing a bot for that is probably an overkill, it's simple enough to check this by hand every now and then.

Where is the source code for https://piped-instances.kavin.rocks/? I think it should be possible to modify it to get a current instance list from a Git repo. From there it should be possible to add some code to use the Github API to open a new issue if a instance is down for long enough.

For the public facing instance Github pages could be used to build a simple front end that queries the instances status page. The static instance list would just be a json that the backend bot queries to list statuses.

I hope I am making sense

[Bnyro]

Where is the source code for https://piped-instances.kavin.rocks/? I think it should be possible to modify it to get a current instance list from a Git repo. From there it should be possible to add some code to use the Github API to open a new issue if a instance is down for long enough.

The code is located at https://github.com/TeamPiped/instances-api/blob/main/main.go. The first step would probably be to create an API endpoint that returns the instances that are inactive. Then it could be used about once a day from a GitHub action to see if there are any broken instances and report them, that's indeed a good idea :+1:

For the public facing instance Github pages could be used to build a simple front end that queries the instances status page. The static instance list would just be a json that the backend bot queries to list statuses.

Makes sense, true.

[Bnyro]

I've added /inactive/30 and /inactive/7for getting the instances with 0 uptime from the last month / week, which should be live at https://piped-instances.kavin.rocks in some hours.

[Bnyro]

I don't plan to spend time looking into writing a GitHub action to automatically remove dead instances, I'd be grateful for pull requests on that!

Adding a guideline about when to remove instances would make sense as well, PRs at https://github.com/TeamPiped/documentation welcome too!

[Darin755]

I've added /inactive/30 and /inactive/7for getting the instances with 0 uptime from the last month / week, which should be live at https://piped-instances.kavin.rocks in some hours.

Thanks for this. It doesn't look active as of yet but I will try it in a bit.

[Darin755]

I don't plan to spend time looking into writing a GitHub action to automatically remove dead instances, I'd be grateful for pull requests on that!

Adding a guideline about when to remove instances would make sense as well, PRs at https://github.com/TeamPiped/documentation welcome too!

I might look into building a simple frontend for the instances API using Github pages. On that page I could simply have a list of instances eligible for removal.

[Bnyro]

It's now live, see https://piped-instances.kavin.rocks/inactive.