I filed an issue on the lemmy and kbin issue trackers to address duplicate communities. If you have an #ActivityPub development experience/knowledge, please take a look and offer feedback. If not, please offer any feedback here.
I wonder if something like a hashtag system, or built in multi-communities would be a good solution. It’s definitely something I’d say needs to be addressed at some point, but I’m not sure what would be a good solution, especially as I’m not yet familiar with the specifics of ActivityPub. The solution you pose seems to be a good step in the right direction.
I’ll also say, I don’t think limiting communities to a single instance is the answer, because if that instance ever goes down for whatever reason, the whole community is gone. It should be distributed across instances by design, imo. I’ve seen some people suggesting this, so I wanted to address it.
What about adding some ability for instances to co-host a community? One single community, but the two instances share the load like a distributed server system? Or even at its simplest, one just acts as a backup in case the other goes down?
A distributed system is different from a federated system and from my understanding, much more complex. If the proposal I submitted is implemented, then I think that would solve your concern.
Imagine !gaming@lemmy.ml and !gaming@beehaw.org follow each other via my proposal. A user who doesn’t know anything about that following relationship can post a link at !gaming@beehaw.org and it can show up in !gaming@lemmy.ml. If either community goes down, the other community should be able to maintain all existing posts. There is the question of what happens to users of the community that went down (they may not know about the other community and can’t visit the community they know about to check its sidebar because its down now)
I’m definitely one of those new users who is really concerned about this. In my opinion the second biggest issue apart from UI improvements. Especially now when it’s still unclear which instances stay online and can handle the traffic.
I think my proposal would make content discovery easier, especially for newer users. But, like I said in the proposal, I don’t think duplicate groups is really that big of a deal. And over time, I think it solves itself. Smaller communities either die off or find their own niche.
If a new user finds a community that they’re looking for, that’s a win. Some other community about the same topic that they don’t know about doesn’t affect them. Maybe there’s conversations happening that they’re not a part of, but there are always conversations you’re not a part of (in real life, on other websites, or even on the website you’re using because you can’t keep up with them all) and nobody seems to have an issue with that. What problems do you think duplicate communities cause?
I submitted this proposal as a FEP
deleted by creator
So posts which go to one community in the group can be seen by users who subscribe to any of the communities in that group in any instance… if that makes sense. But they are still looking at the post from the instance which it was posted to, not a synced copy
This is essentially what I was suggesting. But in order for users to see a post, their instance has to have a copy of that post, otherwise the instance would have to load it from the remote instance every time someone tries to view it.
I was actually just thinking about this earlier today. I definitely think this could turn into a problem. People are drawn to where other people are, so if a new user joins a smaller instance and goes looking for (to use your example) a gaming community, they will see that their smaller instance has say a few dozen posts, but the lemmy.ml instance version might have hundreds, thousands, hundreds of thousands, etc. So where do you think they will mostly look? And if they go to post something, why post it where nobody will see it on the local small community? This isn’t necessarily inherently a problem in a perfect world. If popular communities are spread evenly among instances then it works out, but that is also unlikely to happen as potential users will want to join popular instances for the same reason as the community above…
I’m not at all an expert on the ActivityPub protocol or federation in general, so take this all with a grain of salt. So as to the solution proposed, I don’t quite think that would be a good solution for one main reason which is the duplication of content across instances. Assuming that this solution is used, most instances would want their popular communities to be grouped so that their users have access to the popular content at the very least. But if grouping a community means that all posts, comments, media, etc is shared to all members of the group such that if an instance goes down it isn’t lost, then that could have huge data storage impacts on instances. Say I want to set up an instance with the gaming community example grouped in with the lemmy.ml gaming community with say 10,000 posts and 100,000 comments total. Suddenly I have to have storage for all of that content and any associated media (pictures, video). This means any instance that wants to have the popular content will have huge storage burdens even before a single post is created from their own instance.
So what is my solution? I think instead of syncing all of it across the instances for community groups it should rather be more of a link. So posts which go to one community in the group can be seen by users who subscribe to any of the communities in that group in any instance… if that makes sense. But they are still looking at the post from the instance which it was posted to, not a synced copy. Instances would probably do some caching to prevent lots of queries for popular posts or whatever, but that’s getting too far into the details. The idea would just be to sort of group the subscriptions of the same group rather than the posts of the same group. That does mean that if a instance goes down the content posted from it will go down as well, but it alleviates the burden of hosting all of the entire community group’s content on every instance… so it’s a bit of a compromise.
This does however raise lots of issues with moderation and differing instance rules (NSFW being allowed vs not being one of the most obvious but I’m sure there are more). So it’s definitely a complex issue to solve.
Really like the thinking.
I suspect however that your proposal would dissolve the boundaries between communities too much. And potentially create a problematic amount of work and traffic and confusion across the federation.
I would counter-propose to put the aggregation on the user/client side, where, like on reddit, users can create custom feeds that aggregate multiple communities. This is also, generally, a feature in the fediverse-microblogging platforms.
At the moment, lemmy provides “All”, “Local” and “Subscribed”. So my proposal would be that there’d be a fourth “User” feed, with any number of sub-feeds or filters. Perhaps, speaking of UI, it could just be available as a special filter under “Subscribed”.
Either way, the User would create a feed by listing the communities that would contribute to that feed. Give the feed a name and then view it whenever they like. Given that similar logic is already happening for the “Subscribed” feed, I would imagine that this is a realistic feature
Some additional enhancements could be the following:
- Sharing custom feeds. Allow users to make their feed configurations public so that others, especially newcomers, can copy and get up to speed on where things are in the ecosystem.
- Allow the feed to be sorted with equal or skewed weighting. Lets say you have a custom feed for programming that aggregates two communities, one big and active, the other smaller, less active but no less interesting. You might want your feed to present things from both communities with equal probability. I think this could be straightforward. The idea would be if you’re sorting by “most comments”, you can do so relative to each community’s level of activity, so that the most active post from each community are considered equal in your feed even though one post as 10x the comments than the other in absolute terms.
- Going even further … you could maybe add a custom weighting, so that posts from the less popular community are weighted twice as highly because you’re more interested in it. This may be a relatively heavy burden on the server, but would be cool!
- The Cross-posting UI can list at the top of the communities list those that you group along with the originating community. This way, communities can remain discrete, which is generally a good thing, but cross-pollination can happen as easily as possible.
- For those that don’t know, the icon, underneath a post, with two squares, one infront of and to the bottom-right of the other, is the cross-post function on lemmy.
As for the general idea behind your proposal … that is, allowing communities to align with each other in some way … I think that is still interesting.
In line with my proposal above, maybe what could happen is that community admins can have an easy process for “aligning” with each other, much like your “follow” mechanism. And the result of this is that there’s some button when you’re viewing a community that will provide a list of “aligned” communities which you can then easily add to a new or existing custom “User” feed.