This is in regard to Lemmy.world blocking piracy communities from other instances. This post is not about whether you agree with the decision. It’s about how the admins informed their users.

A week ago Lemmy.world announced their Discord server. This wasn’t very well received (about 25% downvotes, which is rather bad compared to other announcements). The comments on that post were turned off, presumably to avoid backlash.

Before that, announcements about the instance used to be posted to !lemmyworld@lemmy.world. This time, the information was posted on the Discord server instead.

I don’t agree with this. Having to use a proprietary platform to participate in an open-source one goes against the very purpose for me, especially when the new solution isn’t really an improvement (as before the information about the platform was closer to it).

Edit: Corrected the announcements community name.

Update: Lemmy.world finally released an announcement and promised they would inform about similar actions and gather feedback in advance in future.

  • 𝙣𝙪𝙠𝙚@yah.lol
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    1
    ·
    edit-2
    1 year ago

    If the intention is to have an internal, instance-only post, I believe such a thing could be enforced with an automoderator bot. I had a lot of success throwing the Lemmy API into an AI and generating my own moderator bot from that. Could work for you.

    • Ada@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      That’s quite a good idea. Not the perfect solution, but better than anything I’m currently using

      • 𝙣𝙪𝙠𝙚@yah.lol
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        I had an idea about this today but I don’t know enough about Lemmy to confirm it. Thought I’d run it by you just in case.

        Could you create a post and lock it normally, then directly edit the postgres row to unlock the post? I’m wondering if this would federate the lock but not federate your unlock causing all outside users to see a lock and all internal users see an unlocked post.

        Possible edge case: users who subscribe to the community after the unlock will receive the initial data dump of posts and this will include the post in its current unlocked state.

        However, this would be an easy way to block the majority commenting on a post while maintaining a seemless experience for your internal users.