Skip Navigation
45 comments
    • Well... there we go :)

    • And/ or moderators could have setting to automagically display threads from selected communities. Similar to how #tags currently work with the microblog part of kbin.

    • Looks like a great project. Thanks for sharing! Unfortunately I use /kbin :(

      • That would work with kbin magazines too as they are converted to /c/community@instance.tld on Lemmy side.

    • I think this is probably the only way to do it. But they need to be curated by someone. The reason it can't happen automatically is based on how federation works on lemmy and kbin.

      That is that an instance doesn't know about the communities another instance has available (it doesn't even know about any other instances). When a user specifically searches for a remote instance, then it contacts the instance and then knows about it.

      But this change could work in that someone on the instance can search out the various communities and create the merged group.

      Of course when you reply you'd only reply to the community that post was from but actually that's fine because anyone in the combined group would still see it.

  • Didn't plebbit suffer from the same issue in the beginning? As far as I remember it kind of self-resolved itself back then an people migrating from /whatever to /thisIsTheBiggerWhatever.

    I guess it could be handy to encourage mods to keep an eye on it and at some point have their community vote\decide if they want to "merge" or something.

  • Let the competition in the marketplace thrive. Whoever is the stronger opponent will survive.

  • Wasn't there a forthcoming tag-based feature to allow posts to propagate between similar communities/magazines?

    That makes the most sense to me. Because then each parallel community also serves like a pseudo-snapshot of the others, allowing all others to continue without the pain of an interregnum, e.g., in the event of, say, a rogue defederation.

    That wouldn't account for cultural differences between instances though. Where those are drastic, then people should get to choose which one they want to join.

  • KBin/Lemmy should provide a combined local view for duplicated magazines/communities across the fediverse. Treating the concept like a hashtag.

    The point of the fediverse is to distribute content so no one has a monopoly. People squatting on communities/magazines don't understand there is nothing stopping people creating one on a hundred other instances.

    Each kbin/lemmy instance decides to follow magazines/communities from others through activity pub and stores it locally for the instance.

    Having the UI retrieve all local posts with the same magazine/community name (e.g. m/startrek@kbin.social c/startrek@lemmy.world). Wouldn't be hugely difficult, I believe Kbin uses postgres database as the local store and suspect it would be a tweak to the SQL query it runs.

    Even if that wasn't an option, there is a means to get all of the magazines/communities from the kbin UI/lemmy REST API. As well as retrieve all posts for a specific magazine/community. So you could do it entirely in a web client, for KBin it would be more work.

    The combined view wouldn't change how you comment on specific posts. The issue is where do you post and what view would take dominance (e.g. if a magazine had themed itself).

    The solution here would be to default your local instance if it exists or the instance providing the most posts/comments. Perhaps with a drop down so users can choose.

    I would also configure things so instances can select a site wide default if they can't moderate it effectively. For example pushing all posts to the star trek instance rather than local magazine with a mod who is MIA.

    This would remove most of the concerns users have about the fediverse, since they wouldn't be confronted by different instances. To them the fediverse is insert instance it would also encourage distribution of content.

  • Meta-communities in two flawors:

    • user/UI-based, where the user can create an entry in his preferences, add a bunch of communities there and set which one will be its "facade". The main "con" here that every single user should do a lot of work by himself
    • server-based, where you can create new meta-community, add your own community there, and send invites to all similar communities to join. Every community that joined could(should?) be removed from discovery, but be visible as "nested". Search by its name should lead to meta-community. Ownership of such meta-community should belong to its members in term that not a single one could delete it or make any harm. Meta-community exists while there's at least one member in it. Picture of meta-community in discovery could be anything, one can take it from most populated member community, but user could be able to change it in his preferences to any other member.

    Important part that one to be careful about combining feeds. Small cozy community can just dissolve in valley of posts from much larger ones. The thing is controversial, on one hand it's really handy to see all the posts all at once, on the other hand - it can kill smaller communities, as their creators will lose the sense and desire to have them maintained. There are different solutions:

    • Make feed combined, but give posts from smaller community higher priority
    • Make user to switch feed manually and let hit set "default" to show when you open meta-community
    • Give user a choice between two

    To me, manual changing feeds feels more healthy for a smaller ones.

  • İt's very difficult. It will be a feature of uniting/separating communities. This will only visually show the groups as a whole. We will also be able to name this group. In this way, we will be able to see the content on similar topics in different instances as a whole.

45 comments