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.
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.
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 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.
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 problem is 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.
Zagorath@aussie.zone 6 months ago
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.
coffeeClean@infosec.pub 6 months ago
You obviously lack a bit of knowledge about Cloudflare. I suggest reading the link you overlooked:
…noblogs.org/…/cloudflare-has-created-the-largest…
I suggest also understanding a bit about Cloudflare as an organisation:
git.kescher.at/dCF/…/rapsheet.cloudflare.md
Cloudflare is antithetical to every objective of the federation.
Zagorath@aussie.zone 6 months ago
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.
coffeeClean@infosec.pub 6 months ago
Selling your soul for a slightly faster load time is your personal preference but trading off inclusion of marginalized groups so some people get a faster load time is not in line with the netneutrality principles the fedi community values.
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 we get a broken threads. 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.
That’s not true either. Cloudflare gets a view on all traffic, both public and private. Users are deceived because of the lack of disclosures about the CF MitM. E.g. users 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.
No, it’s centralized because Cloudflare controls access. 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.