Open UnderEu opened 1 year ago
What's wrong with only supporting IPv4? Why would you ever want to require IPv6?
What's wrong with owning a horse? Why would you ever want to build infrastructure for trains and cars?
Adding a column about IPv6 support isn't about building infrastructure, I just don't see the immediate need for it. I'm very well aware of IPv4 addresses running out etc etc, I know IPv6 is the future. What I meant is, in what cases is IPv6 currently required to the point that you need to know? Are you unable to access services that only support IPv4? Why do you want to know? It's not like seeing that an instance doesn't support it would mean you can take action and do something about it.
I reverted your changes because it breaks existing parsers, and nobody has yet to come up with an argument for why this is needed, despite 30 people downvoting my comment.
A few Internet Service Providers (ISPs) went IPv6-only by now (by IPv6-only I mean "no native IPv4 addresses on the client"). The one most worth mentioning here is T-Mobile providing mobile data for more than a million users (including myself). You are still able to access IPv4 pages, however, only by using a Carrier-grade Network Address Translation (CNAT). In contrast to at-home-NAT in your router where your household has one address, this causes hundreds up to thousands of users entirely unrelated to each other to have the same IPv4 address causing some of them to run into rate-limiting. This happens for instance on Twitter/X since the most recent severe rate-limiting restrictions as the Twitter/X API is IPv4-only, too.
Similarly, UnityMedia (a large German cable-Internet) provider is using "DSLite" since at least 2015 doing the same CNAT magic for users to access IPv4-only services. I think Vodefone does the same, Comcast surely does and KPN (the largest dutch ISP) does it for new customers since a few years.
Also worth mentioning is that IPv6 Internet access has priority over IPv4 in virtually any recent operating system (Linux, Android, Mac OS, and iOS for years, MS Win since at least version 10). Web addresses are first AAAA
(the IPv6 address entry) requested and only A
when AAAA
returned NODATA
.
Apart from this, the IPv6 internet is about twice as fast concerning round-trip times than the IPv4 internet. The two most important reasons for this are that (a) the computational effort is lower - IPv4 packets need to have their header checksum recomputed on every hop causing some overhead. This overhead is still present even when specialized networking hardware have hardware dedicated for this and (b) packet routing is faster as IPv6 traffic is truly end-to-end so no need to look up addresses in NAT tables on involved routers (this is only a concern for at-home users not ones with public IP addresses).
I also vaguely remember Apple requiring all apps to function IPv6-only since some time to be allowed to stay in their app store but I don't have a reference for this right now.
I know that there is still a lot of apps and services that do not support IPv6. ISPs know this too and that they will still need to provide IPv4 to customers - even if they are doing this on entangled ways through CGNAT. In the end, I don't think we will loose IPv4 at any point in the near- nor mid-future so it is entirely up to you if you want to be part of this or not. Users will very likely be able to access Nitter in the future even without IPv6 on the server.
speaking as an instance operator (nitter.services.woodland.cafe
)
this causes hundreds up to thousands of users entirely unrelated to each other to have the same IPv4 address causing some of them to run into rate-limiting
I don't think y'all realize how much abuse instances are currently suffering from botnet operators who hammer /search 10 times per second to, idk, feed an AI with tweets or something. That is from multiple IPs, but clearly belonging to the same person.
Because most instances are down and the traffic has focused on very few instances. We're at the point where we're banning entire ipv4 ranges because while traffic clearly comes from one botter, it is distributed across an entire subnet or even ASN.
I do not think you will get the effect on rate limits you want out of this in the end. It is too easy/cheap right now for botters to get an entire ipv6 /64 subnet at Hetzner (it is literally free while an individual IPv4 address costs at least 50 cent/mo), so if I ever support IPv6 I am pretty sure I will rate-limit based on /64 subnet, not individual address.
BTW, in the current state of nitter I also really do not care about shaving off a few milliseconds off of roundtrip latency. If I really cared about that I'd do what projectsegfau.lt does and provide multiple instances around the globe, or build some geo-edge-point-of-presence contraption using anycast.
Charging ahead with rogue edits on the wiki that break other tooling due to new columns just causes more work for maintainers, and even talking about IPv6 while nitter master does not work at all feels like rearranging deck chairs while the ship is sinking.
What you say is not an argument against IPv6. I fully agree that IPv6 itself is different and needs its own considerations to reduce abuse. All I'm saying here concerning rate-limiting is that with IPv4 you may falsely attribute several hundreds to thousands of users into the same IPv4 address on the outside while this is not something you could compensate for. In the IPv6 world, you have the liberty to block entire subnets as per your liking instead of having to make assumptions but I do see that this means too much extra work, then this is an argument for not implementing this.
I see no reason to bloat the wiki with more columns that haven't been necessary for the last years - especially since columns like RSS are not part of it, which affect even more people and has an active user group.
As untitaker said: don't change other people's wikis and layouts, especially when the issue is about asking for that change, without any approval. You're just breaking other tools like the status page.
I'm open for adding this as another column to the status page. That way it's up to date and has a better UX than bloating the wiki page. Please do not abuse other people's FOSS projects for your personal political (ipv6) agenda. Accept a no.
you may falsely attribute several hundreds to thousands of users into the same IPv4 address on the outside while this is not something you could compensate for
You get to choose: Effectively turn off the nitter instance as it's running out of requests or inconvenience some users behind an IP that alone makes up 10% of your daily API requests (while using very obvious whole-site-scanning setups). Running out of requests happened in ~15 minutes to 3 hours for new unprotected instances in the past few weeks.
Connectivity detection is now part of the status page. Scroll to the bottom to enable the column for your browser session.
Fun fact: github.com and api.twitter.com still don't support IPv6 (as of 2023.9) .
So if you can only access IPv6 , how could you visit this wiki page to find which instance supports IPv6?
So if an instance only has IPv6 , it couldn't even provide services to you because it cannot fetch from twitter.
Besides, since you think IPv6 is common and the main stream , why should we need a special mark for a such common thing? ( Troll: I propose to add IPv4 mark for instances!)
So if you can only access IPv6 , how could you visit this wiki page to find which instance supports IPv6?
Using the 464XLAT/CGNAT technologies that is provided by your ISP because of lazy adoption.
So if an instance only has IPv6 , it couldn't even provide services to you because it cannot fetch from twitter.
I put tinyproxy on a $0.50/mo OpenVZ server that has IPv4 (behind NAT) and IPv6 then put that in the nitter config file.
Besides, since you think IPv6 is common and the main stream , why should we need a special mark for a such common thing?
The OP didn't say or imply that? Anyway, I guess maybe it's to call out lazy instance operators that are part of the reason we cannot get closer to ditching this obsolete protocol***
It's not that hard to figure out IPv6 though. (especially if you were already capable enough to properly deploy a nitter instance)
***Granted, with the need to rate limit and the lack of off-the-shelf solutions to properly enforce IPv6 prefix banning, it's justified for the nitter instances to lack IPv6 support at this time. That's not the fault of IPv6 itself though.
Needless to say the current Internet Protocol is IPv6 (RFC 8200) and there STILL are websites that don't allow users to reach their pages via this protocol (and refuses to fix this bug).
In order to help others to decide what instance to use, a checkbox alongside all the parameters in the instance list could be added, so aware people of what instances support the current protocol and what instances don't.
Example:
...