The problem:

The web has obviously reached a high level of #enshitification. 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-shit websites, and to only upvote content that has no links or links to non-shit venues.

It’s not working. The social approach is a systemic failure.

The fix:

  • stage 1 (metrics collection): There needs to be shitification metrics for every link. Readers should be able to click a “this link is shit” button on a per-link basis & there should be tick boxes to indicate the particular variety of shit that it is.

  • stage 2 (metrics usage): If many links with the same hostname show a pattern of matching enshitification 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 enshitification 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.

  • activistPnk@slrpnk.netOP
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 year ago

    One man’s bug is another man’s feature. The hair-splitting you attempt here really serves no useful purpose. I’m calling it a bug because input data is overly trusted and inadequately processed. It could be framed as a bug or an enhancement and either way shouldn’t impact the treatment (beyond triage/priority).

    if a tester posted something like this as a bug instead of a change request, it would get thrown right into the trash bin

    Yikes. Your suggestion that it should impact whether it’s treated at all is absurd. Bug reports and enhancements are generally filed in the same place regardless. If you’re tossing out bugs/enhancements because you think they are mis-marked, instead of fixing the marking, I wouldn’t want you working on any project that affects me or that I work on. That’s terrible. Shame on you.

    Side note, do the hash tags do anything on lemmy, or are they just posted here for emphasis?

    They have search index relevance in the fediverse. People outside of Lemmy will find the Lemmy post if they search those hashtags (which are ignored by Lemmy itself).

    • Scrubbles@poptalk.scrubbles.tech
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      1 year ago

      It could be framed as a bug or an enhancement and either way shouldn’t impact the treatment (beyond triage/priority).

      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.