This is likely a Lemmy bug but infosec.pub is related because there are so many Android communities that are federated from bad places so I thought I would mention it here as well.
cross-posted from: https://infosec.pub/post/11060800
The cross-post mechanism has a limitation whereby you cannot simply enter a precise community to post to. Users are forced to search and select. When searching for “android” on infosec.pub within the cross-post page, the list of possible communities is totally clusterfucked with shitty centralized Cloudflare instances (lemmy world, sh itjust works, lemm ee, programming dev, etc). The list of these junk instances is so long !android@hilariouschaos.com does not make it to the list.
The workaround is of course to just create a new post with the same contents. And that is what I will do.
There are multiple bugs here:
① First of all, when a list of communities is given in this context, the centralized instances should be listed last (at best) because they are antithetical to fedi philosophy.
② Subscribed communities should be listed first, at the top
③ Users should always be able to name a community in its full form, e.g.:
!android@hilariouschaos.comhilariouschaos.com/android④ Users should be able to name just the instance (e.g. hilariouschaos.com) and the search should populate with subscribed communities therein.
2, 3, and 4 are brilliant suggestions.
1 is ridiculous. You’re actively asking for a worse user experience. When ordering a search, after 2–4 have been accounted for, order should be descending order of size.
order should be descending order of size.
If bigger is better, why are you here instead of Facebook and Twitter? Fedi principles and philosophy have completely escaped you. In the fedi, we consider power imbalances, privacy abuses, and exclusivity resulting from centralization to not only worsen UX but to be an injustice. Encouraging disproportionate growth in the fedi is to advocate the destruction of what brings us here.
You might prefer smaller instances; I see a lot of value in that. I myself am on an instance that’s almost identical in size to yours.
I do not see the value in smaller communities being prioritised when they each cover the same topic. If there’s !android@lemmy.world with 10,000 subscribers and !android@mypersonalinstance.net with me and my twelve mates, lemmy.world is the one the app should show people first. It wouldn’t matter to me whether that 10,000 is on lemmy.world or midwest.social, it makes sense to show users the place they’re likely to have the most interaction.
I actually didn’t realise which community I was in when I posted that previous comment, and as a user of a different instance I might not have weighed in had I done so. However I will say that:
- This part of it is clearly not a bug, however you put it. It is a difference of preference. There is a worthwhile bug to report here, but it’s around the inability to view more than some number of communities when you search. I think you do yourself a massive disservice by conflating two essentially unrelated issues, one of which is your personal preference.
- It’s not instance-related at all. This belongs in discussion around lemmy-ui, the various Lemmy apps & alternative front-ends, or in Lemmy itself with what gets returned by its search API.
You might prefer smaller instances; … This part of it is clearly not a bug, however you put it. It is a difference of preference.
My personal preference happens to align with fedi principles. Don’t let that consistency fool you. I’m not advocating for what’s best for me. I am saying the list should be ordered in a way that’s healthy for the fedi based on the federation’s purpose and mission.
Showing the biggest communities on top may be your personal preference, but that is not healthy for the federation.
I myself am on an instance that’s almost identical in size to yours.
FYI, aussie.zone is centralized on a US tech giant (Cloudflare) and thus contrary to fedi principles. Though it’s not the worst manifestation of Cloudflare because they have whitelisted Tor. But there are still many other demographics of people likely being excluded from aussie.zone.
I do not see the value in smaller communities being prioritised when they each cover the same topic. If there’s !android@lemmy.world with 10,000 subscribers and !android@mypersonalinstance.net with me and my twelve mates, lemmy.world is the one the app should show people first. It wouldn’t matter to me whether that 10,000 is on lemmy.world or midwest.social, it makes sense to show users the place they’re likely to have the most interaction.
That is not healthy for the federation. That imbalance is a problem that Lemmy has failed to control. The disproportionately large communities need no promotion. Too many people know about them already. They should either not be listed at all or be pushed lower on the list. It’s an extra slap in the face and injustice that these are exclusive Cloudflare instances that are getting prioritized. These are instances without self-control on their growth and power.
It’s not instance-related at all.
It is instance related. If you search for Android on other instances you will get different lists. Users on infosec.pub have subscribed to every Android community in existence which makes the manifestation of the problem unique to infosec.pub. The !android@hilariouschaos.com community is also federated to infosec.pub by way of my subscription. It is true to fedi principles of inclusion and decentralization, unlike those that get listed on the top. So it’s an unhealthy sequence.
It could even be one user account that caused this. The activism.openworlds.info Mastodon instance was getting hammered with traffic. After investigation, they discovered that one user was following a shit ton of other accounts. All those follows were responsible for the admins struggling to cope with all the traffic. That instance eventually went under because it could not cope with the bandwidth demands.
This belongs in discussion around lemmy-ui, the various Lemmy apps & alternative front-ends, or in Lemmy itself with what gets returned by its search API.
The software part of the problem is specifically in the stock Lemmy web client. The bug tracker for the Lemmy web client is jailed in MS Github’s walled garden, hence why it was originally posted in !bugs@sopuli.xyz. There may be a configuration element to this, which is why it’s posted in this infosec.pub community. If there is an inactive account with all these android subscriptions, that can be remedied on the instance.
You know Cloudflare isn’t a web hosting service, right? It just sits in front of actual hosts to help with things like DDOS protection. aussie.zone is hosted in Sydney, Australia. I don’t know about those other instances you mentioned, but if your complaint is only about Cloudflare, it becomes even more ridiculous than it was on first blush.
You obviously lack a bit of knowledge about Cloudflare and how it operates. I suggest reading the link you overlooked:
I suggest also understanding a bit about Cloudflare as an organisation:
https://git.kescher.at/dCF/deCloudflare/src/branch/master/subfiles/rapsheet.cloudflare.md
Cloudflare is antithetical to every objective of the federation. Most importantly: decentralization. You don’t decentralize a platform by giving central access control and traffic visibility to a single tech giant in the US. It defeats the core purpose.
I know well how Cloudflare works. I’ve used it myself at work, and for my personal website. That website you linked clearly doesn’t use it, because it took about 5 seconds to load up despite being entirely text. That’s why it’s a good service.
I find most of the criticisms it describes largely unconvincing in general, but particularly unconvincing in the fediverse. Yes, you can in fact access content on the fediverse without Cloudflare if you really want to. You can choose to use a different instance, and it doesn’t matter where that data is hosted. The fediverse is by design not a privacy-forward platform, so concerns about “content they expect to be private” don’t matter.
It’s still decentralised because each instance is run by its own instance administrators with their own rules and capable of maintaining its own culture. This is the real goal of federation. Nothing about Cloudflare runs counter to that. Even if they were all hosted in the same data centre it would not be a large mark against the fediverse, though there would be some small risk of being deplatformed by the host. That risk exists with Cloudflare too, except that a site previously behind Cloudflare can choose to no longer use it far more easily than a site can move its hosting provider at short notice—plus Cloudflare has a history of being extremely slow to wield that power.
That website you linked clearly doesn’t use it, because it took about 5 seconds to load up despite being entirely text. That’s why it’s a good service.
Selling your soul for a slightly faster load time is your personal preference but arbitrarily trading off inclusion of marginalized groups of people so some people get a faster load time is not in line with the netneutrality principles that the fedi community values. Diversity and inclusion trumps faster load times of some dude in Australia.
Yes, you can in fact access content on the fediverse without Cloudflare if you really want to. You can choose to use a different instance, and it doesn’t matter where that data is hosted.
That’s not true specifically for Lemmy. Images do not get copied. If a LemmyWorld user posts an image in a federated community, everything except the image is accessible on other instances. So those of us in Cloudflare’s excluded groups get a broken threads (people talking about an image we cannot see - we just see the discussion because only text is mirrored).
Even if you are in CF’s included group of those permitted access, if you are on a measured rate uplink you would want to see the size of an image before downloading it. That is something else that Cloudflare breaks. There is no
content-lengthHTTP header. So CF also discriminates against those on measured rate connections.There are also various other circumstances requiring users to visit a thread’s copy on another host. If that other host is Cloudflare, CF’s access restrictions determine whether the user gets access. If bob@fedi-respecting.node needs to revisit an old thread to recall a link, and fedi-respecting.node had to delete the thread in a periodic cleanup to recover disk space, bob might need to access another node directly which hosted the same thread. Yes, I’ve been there. And if that other node is Cloudflared, bob will be blocked if he is in CF’s excluded groups.
Cloudflare’s wall breaks the fedi in so many bizarre ways I should probably start a log of the various circumstances that CF causes enshitification to manifest.
The fediverse is by design not a privacy-forward platform, so concerns about “content they expect to be private” don’t matter.
That’s not true either. Cloudflare gets a view on all traffic, both public and private including access credentials. Users are deceived because of the lack of disclosures about the CF MitM. E.g. users commonly expect a DM to be visible to the admins of both hosts with no idea the Cloudflare also has visibility as well. Most users don’t even know about the existence of CF. Aussie.zone, for example, is not responsible enough to disclose to users that CF has that visibility.
Of course it completely changes the equation when the same single corporation who has visibility on about half all web traffic in the world also has a view on people’s social media DMs and acct creds, it’s an all-eggs-in-one-basket kind of compromise. That abusive level of visibility increases in the extent of the compromise when all that data can be aggregated. So the centralised nature of just the data exposure alone makes it antithetical the fedi philosophy from a privacy standpoint, most particularly coupled with the masses being uninformed about it.
It’s still decentralised because each instance is run by its own instance administrators with their own rules and capable of maintaining its own culture.
Certainly not. It’s centralized by Cloudflare’s access controls on all Cloudflared nodes under a single corporate policy. What aussie.zone is doing is very rare. Cloudflared nodes run with CF’s default access controls, which blindly gives CF blanket centralized authority over who gets access. This goes directly against the purpose of federation philosophy.
Even when a node like aussie.zone whitelists Tor, there are still half a dozen other demographics of people who they uniformly and centrally discriminate against and this is strictly under Cloudflare’s control and beyond the control of aussie.zone.
Even if they were all hosted in the same data centre it would not be a large mark against the fediverse
Of course it would. You have something like 5 of the 7 biggest fedi instances dependent on Cloudflare. If there is CF-wide downtime (regardless of whether it’s all on one data center or more realistically broken logic that’s distributed like cloudbleed was), the benefits of decentralization fails to deliver. Lack of network diversity makes disproportionately large number of people vulnerable to a single point of failure.
