I don’t understand how Lemmy intends to do it when the different instances are federated, if several instances create the same community for example…is that possible?

  • @nutomicA
    link
    54 years ago

    Honestly we wont know until federation is actually implemented to some degree. I dont think it makes sense to automatically merge communities with the same name on different servers, as some other commenters mentioned. That would cause a lot more problems than it solves.

    • TrollOP
      link
      24 years ago

      I don’t really have a firm opinion on this, there would be positive and negative aspects. The goal of my post was to talk about it with you to try to better understand how it works.

      Let’s imagine that there are hundreds of federated servers and therefore potentially hundreds of times the same community names. It might be complicated for users to choose. And it also risks diluting the strength of the communities, so potentially little activity per community… In addition, if different communities are moderated or administered by different people and each has its own moderation or content rules, this can make things complex for the user.

      One can also imagine other solutions, for example instead of following communities, the user could follow hashtags. When he publishes content, he is obliged to put tags on his content. Other users then follow the tags that would replace the communities.

      That might solve some problems, but it might create others that I haven’t thought of yet.

      The advantage is that I can follow hashtags throughout the federation, and keep the power of the federated network without fragmenting communities. There would be no need to worry about squatting community name

        • TrollOP
          link
          5
          edit-2
          4 years ago

          Thanks for the link, I didn’t know there was already a discussion about this. It’s not a simple issue to solve, i think there are positive and negative aspects to both solutions.

          The community solution:

          • (+) Moderation of communities by creators
          • (+) Sense of belonging to a community
          • (-) Fragments content and interactions

          What scares me about this solution is the problems associated with fragmentation. If users who are interested in design, for example, will do a search and find 36 communities on the federation with the name “/design@server.tld”. I imagine that the first reaction will be to choose the community that has the most members, therefore the most content and interaction. I don’t think they will have fun reading all the descriptions, all the rules of the 36 communities, but I could be wrong. One way to limit fragmentation a little bit would perhaps be, when creating communities, to show a list of all the existing communities with the same name. I’m also a little afraid that this fragmentation will result in less interaction between users and that we will end up with many dying communities with no interaction.

          The hashtag solution:

          • (+) eliminates the problems of redundancy or fragmentation of content and interactions.
          • (+) simplifies the user experience
          • (-) no moderation (unless a system is invented to elect moderators democratically)

          What can be problematic with this solution is that we’re going into the unknown, we don’t really have a model to follow. Which from a certain point of view can be a good thing because it also allows you to stand out from Reddit and create a unique differentiation. There is also the aspect related to moderation that remains unresolved, we could perhaps invent an effective or democratic way to elect or remove moderators for each hashtag. In any case, I think we should at least give users the possibility to block/hide certain users or instances.

          • @nutomicA
            link
            24 years ago

            Tbh this discussion doesn’t seem very important at the moment, because it relies on federation already working. In reality there is a ton of work needed just to get the basic federation working, so that’s what we should focus on.

            • TrollOP
              link
              34 years ago

              Okay, I understand. Thanks, I’ll follow the progress with interest then. _

  • @ajz
    link
    3
    edit-2
    2 years ago

    deleted by creator

    • @ajz
      link
      3
      edit-2
      2 years ago

      deleted by creator

      • TrollOP
        link
        4
        edit-2
        4 years ago

        But this means that there can be dozens of different “#opensource@server.tld” rooms, so it would mean that a user who is interested in the topic “opensource” would have to subscribe to all the different rooms?

        #opensource@one.tld #opensource@two.tld #opensource@three.tld …

        I thought that if instance A had a room named “#opensource” instance B couldn’t open one to avoid duplication.

        • @ajz
          link
          2
          edit-2
          2 years ago

          deleted by creator

          • @AgreeableLandscape
            link
            34 years ago

            I think Prismo doesn’t even have communities. Their model is one instance per topic.

        • @AgreeableLandscape
          link
          2
          edit-2
          4 years ago

          It’d be pretty easy to have a “subscribe to community on all supported instances” to auto-subscribe to all the communities with the same name on instances your root instance federates with or doesn’t block, and you can then go in and refine your subscription options by selecting and unselecting individual communities.

          A bigger problem is what we should do with communities that are dedicated to the same topic but have different names. Like /c/foss and /c/freesoftware.

      • @AgreeableLandscape
        link
        3
        edit-2
        4 years ago

        You can tag communities with # and users with @ on Lemmy, so they would be the logical choices. But if we’re going with the Mastodon model it should be @user@lemmy.ml and either #community@lemmy.ml or #community#lemmy.ml.

  • @muirrum
    link
    34 years ago

    Actually something that just came to mind: Maybe communities on one instance are the same communities on every other instance, but mods can be appointed per-instance and remove content on that instance only? I don’t know how practical that is, but it’s an idea.

      • @muirrum
        link
        24 years ago

        An issue I just thought of is how initial instance mods would be appointed (for new instances etc.), but that could be done by instance admins or community vote? Or it could be the first user to subscribe from that instance.

        • DessalinesMA
          link
          64 years ago

          /u/AgreeableLandscape The communities on different instances will be totally different, with its own posts, mods, etc. So instance1/c/news will be totally different from instance2/c/news.

          • @nutomicA
            link
            44 years ago

            Unrelated thought, you think it would be a good idea to send notifications about new comments to everyone above in the comment tree? So in this case, notify you, /u/muirrum and /u/AgreeableLandscape about my post?

            • DessalinesMA
              link
              44 years ago

              I thought about it, because I think that’s the way twitter does it. But IMO for reddit-style it shouldn’t, there are some reddit threads that have dozens of nested comments, where the original parent commenters aren’t even a part of it anymore. I’d personally want mentions to be explicit if they aren’t in a direct response.

              • Serge Tarkovski
                link
                24 years ago

                Totally agree but could it be better to have this setting as an option? In small communities, it could be useful, in large ones could be not. Let’s have a choice.

            • @AgreeableLandscape
              link
              34 years ago

              We could have an option to follow a particular point in the comment tree, but by default I don’t think that would be a good idea since discussion tends to evolve as thread depth increases, and notifying users about every comment can cause problems with most of them being out of context.

            • DessalinesMA
              link
              24 years ago

              Having different servers, many of whom aren’t connected, having different “versions” of the same community, that share some data, but not all, would be infinitely more complicated.

              • @muirrum
                link
                14 years ago

                I see your point, however I think community fragmentation is an issue that will need to be resolved, and having separate communities for each instance won’t help with that.

                • DessalinesMA
                  link
                  14 years ago

                  What if instance A wants to make a /c/news, and have control over it, but that name is already taken?

                  Fragmentation means community owners actually get full control over anything they want to create.

  • Serge Tarkovski
    link
    24 years ago

    Just an idea to think about it. It will definitely require A LOT of work to implement.

    A community can be either on a particular server only or merged/distributed if, say, the mods of the comminuty1@server1 and community1@server2 will decide to merge their efforts and make a merged community. In the latter case, this will be a single community with master-master (or any other type) replication, set up explicitly by its admins.

    After the merge, all the userbase is merged, all posts ratings are also merged somehow. Both mods will decide who will have which rights after the merge.

    A merged community may include more than two servers, the replication is set in whichever way the mods want.

    So, the above may solve somehow the fragmentation problem but depends heavily on collaboration.