cross-posted from: https://slrpnk.net/post/27305158 [https://slrpnk.net/post/27305158] > Just as Facebook wields and abuses disproportionate power over social media, Cloudflare wields and abuses disproportionate power over the web and threadiverse. Richard Stallman prescribes guidance [https://stallman.org/facebook-presence.html] for FB enablers who are at least willing to take some marginal action against FB’s power. I highly suggest Facebook users read his guidance. > > I would never use FB but RMS’s guide conveys basic ideas that can generically be transposed in the centralised fedi context. For years I have practiced a workflow in the threadiverse analogous to RMS’s anti-FB advice to at least do my part in disempowering centralisation. This entails limiting the excessive power of Cloudflare centralised instances, as well as instances centralised by sheer uncontrolled size. Activitypub tries to facilitate decentralised infra, but the Lemmy web UI is actually designed to exacerbate centralisation and the network effect. User diligence is required to counteract it. > > :::spoiler 1. Target your initial post in a decentralised community that merits promotion. > Lemmy cross-posts are designed to link the original community, thus giving more exposure to the first place you post. So avoid putting your initial post in places like LemmyWorld. > ::: > > :::spoiler 2. Cross-post incrementally over time. And delay cross-posting to a centralised community like L/W or sh.itjust.works as long as possible. > Cross-posting in many places all in the same hour may be tempting but it fails to exploit the fact that readers are in different timezones worldwide. Your decentralisation-respecting OP gets more exposure if the cross-posts are time-scattered. > > Since your OP was placed in the decentralised community most deserving of promotion, a delay in posting to other places gives the original place a rightful advantage. This would be comparable to downgrading Facebook by feeding FB older content. > > Ideally you reach a level of discipline of never posting in Cloudflare centralised platforms. But if you lack that kind of resolve, try at least to exercise enough self-control to wait a few days and only resort to posting in a place like LW if the engagement is really insufficient. A middle step would be to post in lemmy.ml [http://lemmy.ml] or lemmy.dbzer0.com [http://lemmy.dbzer0.com] which are disproportionately sized but at least not in Cloudflare’s walled-garden. > ::: > > :::spoiler 3. (Lemmy stock web client) In the profile settings, block these centralised instances: > - lemmy.world > - lemmynsfw.com [http://lemmynsfw.com] > - sh.itjust.works > - lemmy.ca [http://lemmy.ca] > - programming.dev > - lemmy.one > - lemmy.zip > - reddthat.com [http://reddthat.com] > - lemmy.eco.br [http://lemmy.eco.br] > - aussie.zone > - lemdro.id [http://lemdro.id] > - pawb.social > - ani.social > - thelemmy.club > - leminal.space > - lemmy.nz [http://lemmy.nz] > - yiffit.net [http://yiffit.net] > - r.nf [http://r.nf] > - literature.cafe > > That list is ordered by user count. The Lemmy UI is sadly unable to take a whole list as input and they must be entered one by one. Hence why the list above is ordered - so you can start at the top with the most power hungry and work down. > > #### What that does and how it helps > Blocking Cloudflare nodes helps in 2 important ways: > > - Your main timeline will show more decentralised posts. It exposes more content under more balanced power and encourages engagement with contributors who respect that. Your timeline will no longer be 99% posts from centralised venues of concentrated power. > - When searching within the Lemmy UI for a community, the first 15 or so results are the most important slots. In some circumstances like cross-posting, only the first dozen or so communities are even reachable and those slots are mostly hogged by centralised power mongers where you should try not to post. This is due to a poor design of the Lemmy UI but using the block feature mitigates the effects. > > It’s very important to realise that the instance blocks do not block people. You will still see posts from LW users. And you can still even reach LW communities and even subscribe to them if you want. The only effect these blocks have is to prioritise decentralised communities in searches and in the timeline. > > ::: > > :::spoiler 4. (m/kbin stock web client) Block communities on centralised instances. > > This is like guideline 3, but sadly more tedious because there is no mechanism for blocking an instance and there is no way to do it in the profile settings either. It’s more ad hoc. You must visit the community and click “block”. The problem is LW has thousands of communities and you don’t want to spend all day playing whack-a-mole. OTOH, you need not block every community; only the ones for which someone on your node has subscribed. The easiest approach is when viewing the main timeline, click the community of a post from a centralised node and then click block. If you do a bit of that every time you browse the timeline, the timeline will gradually become more decentralised over time. The block list is accessible in your profile as far as removal. That is, you can unblock in your profile. > > ::: > > :::spoiler 5. Exploit the fedi datasets for searching. > If you have a chosen a good (decentralised) host without a disproportionately high number of users, then community searches are going to have overly limited results. Lemmyverse.net [http://Lemmyverse.net] remedies that as it searches a large DB that covers communities not federated to your instance. > > Lemmyverse even tracks Cloudflare nodes so you can filter them out. But sadly, that filtering only works when searching for nodes, not communities. You have to fetch the dataset and code your own SQL statements to filter Cloudflared communities out of the search. > ::: >