In the last weeks Lemmy has seen a lot of growth, with thousands of new users. To welcome them we are holding this AMA to answer questions from the community. You can ask about the beginnings of Lemmy, how we see the future of Lemmy, our long-term goals, what makes Lemmy different from Reddit, about internet and social media in general, as well as personal questions.

We’d also like to hear your overall feedback on Lemmy: What are its greatest strengths and weaknesses? How would you improve it? What’s something you wish it had? What can our community do to ensure that we keep pulling users away from US tech companies, and into the fediverse?

Lemmy and Reddit may look similar at first glance, but there is a major difference. While Reddit is a corporation with thousands of employees and billionaire investors, Lemmy is nothing but an open source project run by volunteers. It was started in 2019 by @dessalines and @nutomic, turning into a fulltime job since 2020. For our income we are dependent on your donations, so please contribute if you can. We’d like to be able to add more full-time contributors to our co-op.

We will start answering questions from tomorrow (Wednesday). Besides @dessalines and @nutomic, other Lemmy contributors may also chime in to answer questions:

Here are our previous AMAs for those interested.

  • Zagorath@aussie.zone
    link
    fedilink
    English
    arrow-up
    8
    ·
    3 days ago

    I don’t follow. I’m on AZ, you’re on LW. We can talk to each other right here, in this community on ML.

    Sure, account migration in some form might be nice, but we certainly are able to

    interact with community A on instance B and also commini X on instance Y

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

          That’s the problem: the protocol pretty much requires explicit relationships between instances since they are forced to proxy/cache each other’s content. I think there’s too much responsibility on the instance… I feel it would be a moderation nightmare to host an instance with truly open federation (potentially even result in legal trouble!). So I totally understand why so many instances want to be conservative on who they federate with…

          The ideal situation would be to be to be able to interact with third party instances directly (at least when the 2 instances don’t wanna agree on caching each other’s content), instead of having to use your home instance as proxy/cache… so the home instance would not need to have the burden (both legally and in terms of hosting resources) and it would just act as a way to identify the user, not necessarily as the primary content provider.

          • Gorgritch_Umie_Killa@aussie.zone
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            2 days ago

            Okay, i think i’ve understood what you’re saying here. I’m not sure it works with the example for Beehaw.

            I think i get what you’re saying. Especially if i consider a large instance like LW’s point of view. A large/general instance where large numbers of disparately opinioned users have gathered, freedom of association must necessarily be more individual to the user themselves than the instance as any kind of individualised entity.

            Remembering the comments around the beehaw defederation, this was a case where a group of like minded people on their instance acted as a group to disassociate from the wider basket of instances. Their instance has an individual identity they wished to protect.

            I feel like the discussion assumes an individual users wish for seemless interactions is more important than the wish of other users to have the choice of non-interaction. I think the assumption should be they are equally as important?

            @blaze@lemmy.dbzer0.com

            • Ferk@lemmy.ml
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              2 days ago

              Their instance has an individual identity they wished to protect.

              If the intention of the separation were to prevent any interaction from anyone who isn’t an existing Beehaw user they would have closed the sign ups. But they didn’t do that (https://beehaw.org/signup is open).

              The reason of Beehaw’s defederation has more to do with moderation hurdles, and how they don’t trust content coming from other instances, see Beehaws own statement about this: https://docs.beehaw.org/docs/important-questions-decisions-and-reflections/on-defederation/

              Like I said: the way the federation works, it’s a moderation nightmare to be fully open. Not because as an instance host you wanna hide the content you have in your instance from the wider public, but because you have to deal with (host, mirror, cache and display along with your own content) content that is coming from a different instance which might not share your same moderation strategy.

              I feel like the discussion assumes an individual users wish for seemless interactions is more important than the wish of other users to have the choice of non-interaction.

              Both are reasonable asks. If a community wants to control who is allowed to access, there should be moderation tools that limit interaction to anyone who’s not been approved. However, this is a different thing from straight-up disallowing in your instance access to all users that happen to have registered their account in a particular instance. I don’t see why the identity/account provider cannot be separate from the access management and content moderation.

              In fact, I feel that it would make access control EASIER for Beehaw if all new accounts actually were accounts from other instances, because that would let them audit the person applying for access in a more reliable way than they do currently in their signup form (https://beehaw.org/signup ). They would be able to check the post/comment history of the user, how many years has it been an active member, etc. before deciding if the user should be allowed to post content in their instance, and it would be protecting them from malicious actors / bots that might be pretending to be someone else. It would also potentially allow to use tools to check automatically the user for common bad patterns, which could potentially minimize a lot the human work in moderation and make the process much faster and convenient also for the person applying, so I feel this is a Win-Win if anything, not an “X has priority over Y”.

              I think granular access control for communities and some other things that are coming will help when it comes to moderation tools. But it still cannot avoid having to deal with all the content from other instances in the federation, since that’s something fundamental in how activitypub works. There would need to be a new separate protocol for decentralizing the user identity between instances that don’t federate their content. Maybe something like OpenID.

          • Gorgritch_Umie_Killa@aussie.zone
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            1
            ·
            2 days ago

            But i have the impression the people over at beehaw don’t wish to interact in such an open way as many other instances do.

            So the decision to disengage should be treated as equally as important as those wishing to interact?