• nutcase2690@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    4
    ·
    8 hours ago

    Although I realize something like this might not be possible, i’d love (in a theoretical perfect world) a delegative/liquid federation. where you can “delegate” your blocklist be an aggregate of other people’s blocklist, which would allow a community of users independent of any admin to create a decentralized blocklist based upon mutual trust. To word it with an example, if I trust user A, who in turn trusts user B and C’s idea of who(/what communities) to block, i’ll then be blocking the same people as user B and C.

    It could work in reverse too, if I trust user A who allows anime communities and user B who allows game communities, then I can see anime and game communities. If people trust me, they can see the same thing i’m seeing. Imo that would spur user interaction and make a decentralized way to not put any one person in power. If user B suddenly decides to only trust fascists, I don’t have to trust them anymore and those changes would be propagated.

    I don’t know if that made sense, so sorry if that explanation is wack! It is loosely based on this concept that I read from awhile ago, for which I haven’t thought of the possible downsides.

    • interdimensionalmeme@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 hours ago

      Will not happen on lemmy, structurally the power flows from instance owners and their delegates. Their power to shape discourse and association and to steer thoughts of the lemmy user will not be relinquished. The first fundamental block to this, like on mastodon, is their power to silence and eliminate users from lemmy history without recourse and with transparency at their discretion.

    • futatorius@lemm.ee
      link
      fedilink
      English
      arrow-up
      2
      ·
      4 hours ago

      I don’t believe the transitive principle of trust that you cite is all that workable, unless it can be done at a finer granularity.

      In my own case, I (A) trust B and C. But B doesn’t trust C, for reasons that have conditioned my relationships with both B and C so that I can still trust them. The reason for that is that trust is multifactorial: A can trust B for some things, not others. So what we’re trying to model is an ontological relation, not just a directed acyclic graph.

      Based on that, the best we can probably achieve is being able to set the degrees of separation of delegated trust (maybe 2 hops and that’s all in my case), and add the ability to subclass or otherwise tweak someone else’s blocklist (say, B’s a fine person but habitually forwards Joe Rogan crap that I find to be nothing but vexatious noise), or C despises my favorite band but is otherwise quite sound, etc.

    • Allero@lemmy.today
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      6 hours ago

      That’s a cool concept, but there are indeed some caveats to address, especially with the propagation part. For example, if you rely on user A to filter you gaming posts, and they suddenly decide they’re not into gaming anymore, you and everyone who relies on you will not get gaming feeds anymore. Or if he is a sudden Nazi, not only you but people who trust you will get that content until you react (and until then, some others will unsubscribe you).

      With a complicated enough network of trusted people, this will trigger a chaotic chain reaction that will make your feed less stable than a chair with one leg.

      Also, conflicts should be resolved somehow. If a person A whitelists some content and person B blacklists it, and you follow both, what should be done?

      One way to go about it is to create a limited list of authorities, but that obviously comes with the danger of someone having too much power. You can make groups of people vote for inclusion or exclusion of topics, but it’s not feasible to vote for every single filter because there are simply too many. You can elect someone to do this, but we know what may happen to elected officials.

      • futatorius@lemm.ee
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 hours ago

        and they suddenly decide they’re not into gaming anymore, you and everyone who relies on you will not get gaming feeds anymore

        I was thinking along the same lines for different reasons. For multi-hop trust delegations, I’d really want a way to see what I’m seeing through the composition of all those blocklists. And once I’ve seen that, a “flatten into my own blocklist” command might be interesting: I want a snapshot of how A through B through C would look, and I’d like to mash it down into my own list so I can manage it there.

        If a person A whitelists some content and person B blacklists it, and you follow both, what should be done?

        Merge conflict alerts, just like version-control systems use? Allowing an order of precedence would be another way, but I think it’d get messy fast.

        • Allero@lemmy.today
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          2 hours ago

          I imagine merge conflict alerts would be very common as well as it all grows.

          Ideally, no user configuration on an everyday basis should be required.