After moving here from lemmy.world after learning of their view on federation with Threads, I now face a dilemma which I do not have a clear answer to.

Should I continue contributing to my niche communities on Instances federating with Threads, or build similar communities on other Instances blocking Threads?

I have a feeing this issue is not a one off, but a common one going forward, so it’s better to settle it once and for all. Below is my thought so far. What would you do in my case?

I love to post or comment on my favourite niche communities to share my experience with others and grow them. Those communities are small in size and they usually exist in certain instances only.

One one hand, having everyone in the same place would be much more beneficial since the community is not split and spread across the fediverse. We would also have better discussions with people from different background and diverse point of views.

On the other hand, I do not feel my contribution is in the right place anymore, if let’s say I post on lemmy.world. I don’t want Threads to benefit from my posts/comments and I want people to join Lemmy. Why would Threads users join Lemmy if they could subsribe to our communities?

I wish my communities were instance-independent so this barrier can be removed. I can create a similar community here but it is the last thing I would want to do.

Having written all these down, I realised this was exactly the same situation how I came to Lemmy from reddit, i.e. communities split across Internet due to issues we have with the platform/instance we are on. I guess discussion on platform/instance-independent communities can be a topic of its own

Edit: formatting and clarified my points and updated my question to reflect that

  • Lvxferre@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    I’ll answer on general grounds.

    I don’t think that there’s a single correct answer for that. Each case is a case; you need to balance how important are your political views vs. centralisation for you, and decide your course of action.

    A few highlights:

    • The difference between a bag of spilling versus putting your eggs in different baskets is just point of view. More comms about the same topic = if one of them goes down, the others still survive.
    • Users can subscribe to multiple comms with the same topic. That’s what I do with cooking comms, for example - !cooking@lemmy.world, !cooking@lemmy.ml, !food@beehaw.org, I’m in all of them, and I (as a user) see no problem with this.
    • Somewhere down the road I predict that the devs will going to allow users (or perhaps the mods) to “group” comms across instances, to visualise their content together. So the bag of spilling will get better over time.
    • Remember that comms don’t just abide to the instance rules, they also set up their own rules. If your issue with the instance is that it lacks a specific rule that you feel to be important, you might want to talk with its mods to actively set that rule up.

    Based on that I think that the problem is smaller than it looks like. If you don’t like the comm about that topic, for whatever reason (including the instance that it’s hosted on), by all means, create another elsewhere.

    • tenth@lemmy.mlOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Sorry I asked the wrong question. I’ve updated it. My question should have been specific to Threads federation. You can see my clarifie point of view in another comment

      Would this change your answer

      • Lvxferre@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        On broad strokes my answer is still the same, we need to weight both things. It’s just that in the case of Threads the political factor weights too much, for anyone who cares about the Fediverse, that “build your own comm elsewhere, don’t use Threads or instances federating with it” should be the default answer.