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.

  • murd0x@lemmy.mlEnglish
    14·
    3 days ago

    Is there a way to move myself as an user from one server to another?

    • nutomic@lemmy.mlOPMEnglish
      9·
      2 days ago

      You can export your settings, community follows etc and import them in another instance. Moving your existing posts and comments doesnt work well with federation.

    • murd0x@lemmy.mlEnglish
      2·
      3 days ago

      I was thinking this cold prove necessary in the context of different servers policies. Got example, if my server would change policies to something I am not willing to agree, then it would be nice to migrate to another server

    • PlungeButter@lemmy.worldEnglish
      35·
      3 days ago

      This is the huge disconnect between what the fediverse is and what the users actually want.

      Users want the convenience of a single entity that floats around the different instances. They want to interact with community A on instance B and also commini X on instance Y.

      But most clients deal with it by letting you log in with multiple users on multiple instances

      • Zagorath@aussie.zoneEnglish
        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.mlEnglish
              3·
              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.zoneEnglish
                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.mlEnglish
                  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.zoneEnglish
                31·
                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?

      • can@sh.itjust.worksEnglish
        4·
        3 days ago

        Users want the convenience of a single entity that floats around the different instances. They want to interact with community A on instance B and also commini X on instance Y.

        I’m not sure I’m following what you’re describing here because I feel like I do have that convenience?

        Disclosure: I have forgotten about my Beehaw account long ago.