We should implement this as whenever I wish to browse (for example) [email protected] I have to go to there, and whenever I wish to browse [email protected] I have to go there. Would it be possible to implement it in kbin/lemmy’s code to make it easier to browse all?
Another kink to think about is what if you have different communities with the same name on different servers with completely different content. Like what if the trees subreddit came to a server and created a marijuana themed community called trees, but then another server wanted to discuss actual trees so they called theirs trees too. Wouldn’t want those two being grouped together automatically.
This is a good point. Maybe communities could have tags or something so people can browse multiple communies based on a particular theme or interest.
This feature shouldn’t be implemented on the server side or decided by the front end code, as the developers would have to decide which “same names” to merge. It’s the end user who should pick that.
It would better be a front end/app feature: The end user would pick communities from multiple servers (even ones with different names), and group them under whatever name/category they want. The front end would then show all posts/comments from that group as they were from a single community.
Additional feature: Automatically merge comments from cross-posts.
Yeah this would be great. Even user defined ‘multi-communities’ would be great for putting all my gaming, news or meme related communities into one scrollable page.
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.
Well… there we go :)
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.tldon Lemmy side.Great news!
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.
I just don’t think this is a problem which needs to be solved. On Reddit it’s common to have different subreddits focussed on the same topic. For example, r/Games and r/Gaming. The only difference on Lemmy is that they’re now m/[email protected] and m/[email protected]. Yeah, it’s slightly longer, but super easy to solve using UX tweaks in the front end.
What’s more, this proliferation of communities across instances is critical for a reasonable user experience because of the apparent widespread support for defederating from instances which aren’t ideologically aligned. If people get comfortable with using one uber gaming community on one instance, that instance could disappear from one day to the next because of a capricious instance owner.
It’s much worse in Lemmy due its “federative” nature. For example, for “Dungeons&Dragons” - in reddit you have 9 subs in search, 2 of them are memes-related, 3 are “general” ones, 2 for DnD5e, 1 for DnD3.5 and 1 for UK people. They have clear distinction at least in their names, and sometimes have separate “theme”, like the one for 3.5 edition. In lemmy we already have 14, most of them have same name, literally letter to letter. And don’t forget that lemmy’s userbase is ~6000+ times less than reddit. People just continue to create new instances and same comminities, over and over.
Easy, just create the equivalent of multireddits.
There are dozens of D&D related subs on Reddit, and many of them overlap a great deal. There is nothing stopping people from creating as many D&D related subs as they like, and people have obviously done that. It’s just that you don’t visit the small ones because of a lack of content. I’m not seeing the practical distinction here. You’ll subscribe to the Lemmy communities with content and ignore the rest.
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.
Use the full name and learn to live with it
So subscribe to half a dozen technology@… subs? I guess we can but surely in the long term there is a better way to merge the content of identically named subs so you subscribe to 1 and get the content of all of the others? If the fediverse is going to thrive and expand they need to fix it for the average user who doesn’t understand how all this works. Tags would be the best way, to automate it.
Identically named does not imply identical. Could be totally different communities with the same name. Or there could be subtle but important differences.
Likewise differently named does not imply that two communities are not essentially the same.
Having some form of grouping could be an idea that might be useful to some. I imagine different people would like it to function in different ways.
But it is entirely orthogonal to naming. At the end of the day abc@instance1 is a different name than abc@instance2.
deleted by creator
This is an issue I’ve been wondering about, the Technology example is fine, but the real edge case IMO is Official Communities.
Like, let’s say I have an Android App and want to migrate my official community to Lemmy. I could build a community in:
- A big and general instance to gather more users, like Lemmy.World.
- A big but themed instance, like Lemdro.id. It has a smaller number of users but they are more likely to be interested in my App
- I could make my own instance, which would allow me to dedicate communities into topics and I would have more control over it, which is good cause it is an official community.
I feel there should be a way for “sync” communities in those cases. It makes sense in those cases to allow a full sync, with the option to unsync if things go south and there’s a split.
I think for official communities self-hosted instances feels like a win-win for everyone. Companies get full control of their community but no one has to participate with it in isolation. They can also separate discussions, eg [email protected] or [email protected].
For more abstract themed communities lime technology it’s definitely more complex. Reddit’s partial solution is multi-subreddits which could apply here but it’s far from a complete solution.
The issue with that is that an user could be on a popular instance, like lemmy.world or a related one like lemdroid, and search for a community on it. They could find a ghost community that was created unofficially before the self-hosted one. In that case they could think this is it and there’s no real discussion to be had on Lemmy.
It is also slightly weird because there’s an incentive for developers to grab the [email protected] to ensure they can use the name and link it to the official instance. But that also leaves a ton of pretty much barren communities.
That’s why I think keeping in sync would be a good feature, keep all communities in sync with the official one so that users aren’t lost.
That said, this only works for official communities, and maybe(huge maybe) regional communities that have a self hosted instance
The practical solution for that, is to simply search the topic you are interested in plus lemmy on google. Chances are best that you will find the most active community.
Since reddit’s search feature was completely unusable for the majority of its history, for me that is just “business as usual”. Though it would be nice to have a more integrated solution.
Alright but what if there was an active community that moved to a self hosted one? Wouldn’t that still show the older community first?
deleted by creator
Doesn’t it place higher the communities that are on the same instance as the user?
deleted by creator
I’m currently using Connect (the android App) and search is even funkier, to the point where it order is frankly random, and it appears to only show “famous” instances or the ones I’m subscribed to at least a community.
I know this isn’t intended, but I can’t help but feel that if sync was possible, this wouldn’t be a noticible issue
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/[email protected] c/[email protected]). 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.
can each kbin/lemmy/etc. also query the upvotes/boosts/likes from all instances and combine them to create ranking(s) of posts that represent the interactions from the whole user base?
You engage with the communities you prefer, just like at the other place. Some will be more active, some will have better posts, some will have better people, some will be more specialized to what you’re interested in, and you engage in those.
İ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.
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.
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 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.
Important part that one to be careful about combining feeds. Small cozy community can just dissolve in valley of posts from much larger one. 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:
