lemm.ee has shut down at 00:14 UTC.

unfortunately I realized too late that I have had hundreds of saved links to posts and comments from there, so I did not have enough time to save them, but anyways it is interesting that maybe a third of the post links I could try were dead. I think linkrot is happening much faster here than on reddit, even if just counting deleted posts.

    • TheObviousSolution@lemmy.ca
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      5 hours ago

      What do you mean? The authenticator instance could ban users, the moderators and the content provider instances could ban users, content provider instances could defederate from authenticator instances and viceversa.

      Not sure I’m seeing the issue you are seeing, it’s just basically forcing lemmy instances to instead of being both to just be one or the other. The benefit is that the actions on one is free from the drama on the other. One would be dedicated to hosting users, the other would be dedicated to hosting communities, less burnout overall.

      • Blaze (he/him) @lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        5 hours ago

        Complete bans (at the home instance level) would require synchronization between the content provider instance and the authenticator instance.

        Mod actions are caused by users comments on content, so the two aspects are closely intertwined, you can’t dissociate the content from the users.

        At the moment, admins synchronize in a group to deal with toxic users, usually leading to the ban of those users on their home instance. Having a split between two types of admins adds an additional layer that could actually increase the admins workload.

        • TheObviousSolution@lemmy.ca
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          2 hours ago

          Complete bans (at the home instance level) would require synchronization between the content provider instance and the authenticator instance.

          What are you referring to as a ban? Complete bans already require synchronization between different federated instances. Sometimes the home instance of a user is unable to entirely delete the content of a user because of it.

          Mod actions are caused by users comments on content, so the two aspects are closely intertwined, you can’t dissociate the content from the users.

          Not really. Mod actions are over a community, not user history. They are perfectly able to remove user comments within their community, and since they are the authoritative source that controls whom it is spread to that has greater influence. That never stops the same content by the same user from appearing elsewhere.

          At the moment, admins synchronize in a group to deal with toxic users, usually leading to the ban of those users on their home instance.

          They would still do the same, but the “usually leading to the ban of those users” perhaps does more to reveal what your actual problem is than anything else. You and me will have to disagree, because admins should not be authoritarian figures, but should only have control within their domain.

          • If they want to administrate over a group of users, they can have control over which users are and aren’t allowed over that particular group. They can issue their own warnings to users.

          • If they want to administrate over communities, they can have control over which communities are allowed and how users are allowed to interact with those. They can remove users from those communities entirely.

          The small but loud minority of toxic users can just have their authentication instances defederated if those instances refuse to do anything with them. If it is an authentication instance doing the defederation, then it will affect all of their users. If it is a content provider instance, it will affect all of their communities. In the current system, it does both because both are coupled into the same instance, so it’s even compatible with it.

          It stops bad faith actors from trying to pollute communities to slur entire instances, like lemm.ee or blahaj, because of their problems with their userbase, by simply stopping it from being an issue. Administrators don’t have to worry about policing communities or users if they don’t want to, they would be able to better choose whom they are catering to without bad faith backlash elsewhere.

          Almost nothing of the current structure changes, except that dedicated instances have the functionality they don’t need disabled. Both can still block each other to their heart’s content, and if your problem is having more “splits” - that is literally what federated instances are, there can always be more … Maybe your problem is with the fediverse and its distributed nature? You are making it out to be as if there is only ever a big bad group of toxic users and that all administrators always completely agree on all bans to make your argument work. At that point, just create your own reddit clone.

          • Blaze (he/him) @lemmy.dbzer0.com
            link
            fedilink
            arrow-up
            1
            ·
            1 hour ago

            I addressed a few of your points in the parallel thread with @Ferk@lemmy.ml (actually, it seems like you read it as you commented below)

            As I stated in one of the comments

            At that point, the content instances would be merely storage. This model is already possible now, but the vast majority of instances host both users and content, because it is more interesting to have users to build a local community than just being a storage server.

            If some admins were interested in only being storage servers, you would see more instances not allowing user registrations, but all the 35th most active instances allow them: https://lemmy.fediverse.observer/list

            I had a second look, and instances not allowing sign up are either going to shutdown (lemmy.one) are false positives (https://bookwormstory.social/signup) or are single-person instances:

            Your vision is possible now, but it seems like almost no one wants to implement it.

            • TheObviousSolution@lemmy.ca
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              52 minutes ago

              Why would people want to implement something they don’t know the benefits of? That’s what my comment and increasing awareness is all about, in a thread about an outcome that could have been prevented by the idea.

              • Blaze (he/him) @lemmy.dbzer0.com
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                9 minutes ago

                If admins goes missing like the feddit.de ones did, the same problem would still impact that instance, be it a user or a content instance

                If admins just want to shutdown without willing to transfer the instance / domain like the lemm.ee ones did, the same problem would still impact that instance, be it a user or a content instance

                Using instances with non profit like https://fedecan.ca/en/ (lemmy.ca and piefed.ca) seems a better way to mitigate that risk.

        • Ferk@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          4 hours ago

          Since he said that the authenticator is the one that handles the communication & access, I expect banning the person from the authenticator would already automatically prevent anyone using that authenticator (or any other authenticator federating with it) from seeing the content.

          As I understand it, the only thing the content provider would do is hosting the data. But access to that data would be determined by the service doing the access control, in the same way current instances are doing it.

          • Blaze (he/him) @lemmy.dbzer0.com
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            4 hours ago

            the only thing the content provider would do is hosting

            Hosting involves removal of content, which is triggered by actions performed by users.

            At the moment, if a Lemmy.world user spams CSAM content everywhere, other admins can reach out to the LW admins, they ban the users and purge the content.

            In a users/content model, with Lemmy.users and Lemmy.world still being the content, other admins have to reach out to the Lemmy.users instance, get them banned, then to the Lemmy.world admins to trigger the purge of the content on the communities.

            On top of that, it is currently recommended to mod from local accounts, as report federation will be fixed in Lemmy 1.0, not released yet: https://github.com/LemmyNet/lemmy/issues/3781

            The main part of the “admin burnout” comes from the management of users. There isn’t really that much to manage on the content part that isn’t linked to users.

            • Ferk@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              4 hours ago

              Hosting involves removal of content

              Exactly. That means instances would not longer have that responsibility. That would be on the hosting service, meaning less pressure for the instance. Once they ban the user, the content would not be shown, it would be purged from the federating network of that instance, regardless of whether the hosting service actually deletes it or not (but I expect it would be better if the protocol makes it so banning a user sends a notification to the hosting service).

              At the moment, if a Lemmy.world user spams CSAM content everywhere, other admins can reach out to the LW admins, they ban the users and purge the content.

              It’s more complex than that, at the moment, because the purge also involves mirrored content in other federating instances. The interesting part is that after it’s triggered, then the process is pretty much automatic. When purging, Lemmy.world admins don’t have to manually go around asking to all the other instances to delete the content. The purge request is currently being notified automatically to instances federating with it. Why would it be any different for a content hosting service?

              • Blaze (he/him) @lemmy.dbzer0.com
                link
                fedilink
                arrow-up
                1
                ·
                4 hours ago

                Exactly. That means instances would not longer have that responsibility. It would be responsibility of the hoster, meaning less pressure for the instance. Once they ban the user, the content would not be shown.

                At that point, the content instances would be merely storage. This model is already possible now, but the vast majority of instances host both users and content, because it is more interesting to have users to build a local community than just being a storage server.

                If some admins were interested in only being storage servers, you would see more instances not allowing user registrations, but all the 35th most active instances allow them: https://lemmy.fediverse.observer/list

                The interesting part is that after it’s triggered, then the process is pretty much automatic.

                There have been cases where federation deletion was not processed correctly, so it would add an additional layer of potential issue

                Why would it be any different for a content hosting server?

                As I stated above, it is currently recommended to mod from local accounts, as report federation will be fixed in Lemmy 1.0, not released yet:

                What that means is that on top of your Lemmy.user account, you would need a Lemmy.content account that would be able to fully moderate the community as a local account. Users don’t like to juggle between different accounts to moderate and participate.

                • Ferk@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  3 hours ago

                  it is more interesting to have users to build a local community than just being a storage server.

                  Imho, it comes down to how much you care about the content of the community you are building. The reason I’m in lemmy.ml and not some smaller instance is because of problems like the ones showcased here.

                  If I could self-host my own content I would not mind being somewhere else. In fact, I’m considering setting up something through brid.gy. The fact that there isn’t a separation of the hosting means that if I want to secure my content I need to have my own 1-person instance which is not something the protocol is very well suited for. Plus it’s likely most lemmy instances would not federate with it anyway since, understandably, they may prefer an allowlist approach rather than blocklist. The only sane way would be to have the instances have full control of the access as they are now, with storage being in a separate service that can be managed separately, the hosting service.

                  it is currently recommended to mod from local accounts

                  Would this change at all if there was a hosting service?

                  I expect you would still be recommended to mod from local accounts (the “authenticator”), even if the content hosting was a separate service. The local account would continue being the primary source of access to the content… note that having a separate hosting service doesn’t mean that the hosting service must be the one managing access to the content from the fediverse.

                  • Blaze (he/him) @lemmy.dbzer0.com
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    3 hours ago

                    The reason I’m in lemmy.ml and not some smaller instance is because of problems like the ones showcased here.

                    Quite a few instances are managed by non-profits which are much less prone to service disruptions, like https://fedecan.ca/en/ for lemmy.ca.

                    The local account would continue being the primary source of access to the content…

                    Isn’t that contradictory with the users - content separation?

                    note that having a separate hosting service doesn’t mean that the hosting service must be the one managing access to the content.

                    That seems contradictory with the previous point. My understanding was that

                    • users would use Lemmy.user accounts to browse content (this is the recommended way to avoid user management for the content instance admins)
                    • mods would use Lemmy.content accounts to moderate communities (users would have to switch to those type of accounts from the first type if they want to start / mod a community)

                    Is this correct, or am I missing something?