The problem:
The web has obviously reached a high level of #enremovedification. Paywalls, exclusive walled gardens, #Cloudflare, popups, CAPTCHAs, tor-blockades, dark patterns (esp. w/cookies), javascript that makes the website an app (not a doc), etc.
Status quo solution (failure):
#Lemmy & the #threadiverse were designed to inherently trust humans to only post links to non-removed websites, and to only upvote content that has no links or links to non-removed venues.
It’s not working. The social approach is a systemic failure.
The fix:
-
stage 1 (metrics collection): There needs to be removedification metrics for every link. Readers should be able to click a “this link is removed” button on a per-link basis & there should be tick boxes to indicate the particular variety of removed that it is.
-
stage 2 (metrics usage): If many links with the same hostname show a pattern of matching enremovedification factors, the Lemmy server should automatically tag all those links with a warning of some kind (e.g. ⚠, 💩, 🌩).
-
stage 3 (inclusive alternative): A replacement link to a mirror is offered. E.g. youtube → (non-CF’d invidious instance), cloudflare → archive.org, medium.com → (random scribe.rip instance), etc.
-
stage 4 (onsite archive): good samaritans and over-achievers should have the option to provide the full text for a given link so others can read the article without even fighting the site.
-
stage 5 (search reranking): whenever a human post a link and talks about it, search crawlers notice and give that site a high ranking. This is why search results have gotten lousy – because the social approach has failed. Humans will post bad links. So links with a high enremovedification score need to be obfuscated in some way (e.g. dots become asterisks) so search crawlers don’t overrate them going forward.
This needs to be recognized as a #LemmyBug.
It absolutely changes priority and how it’s treated. Bugs are things that are actively broken, meaning specifically that the functionality already exists, but it is non-functional/broken. Bugs are prioritized obviously because something that should be working is not.
You are asking for an enhancement, which should be prioritized by dozens of factors, namely who wants this, how does it stack up against other things that other people want, how much effort will it take, and how much of a change would it be, just to name a few. We are not a part of that process, but you can submit a request on GitHub. Doing it here means pretty much nothing, unless you link the GitHub task and ask people to vote for it.
Or, you can write it yourself and submit a PR, making a write up on why you did it, why you think it’s useful, and why it should be accepted into the upstream, and then the maintainers can choose to include it or not, again based on theirs and the community feedback.
We developers aren’t “splitting hairs”, we’ve seen this trick from crappy PMs dozens of times. Half baked feature requests disguised as bugs. We all see right through it. You want a feature, then get the buy in and go through the necessary steps like everyone else, but don’t treat us as morons who will fall for your obvious " well it should work the way I want it to, thus it’s a bug" b.s.