That sounds like it’d be fantastic for reading but, depending on how it’s implemented, hell for posting.
Lemmy already aggregates posts from communities you follow into one feed. If it allowed the creation of an arbitrary number of sub-feeds configurable by the user, that would be incredible. But every user would have to build these on their own from scratch. Great for user choice, but no communities will come bundled by default, so small communities won’t get a discovery boost.
If instead there was some kind of first-class notion of a “supercommunity” offered on the server side, where it acted as a transparent view of other communities, that’d be a great visibility boost for small communities. But if you tried to post to it, which underlying community would it post to? You’d have to either designate a default community to receive posts (which would be unfair to every other community there), randomize where it goes to (which would be a quagmire, what if your post is allowed in half of the communities present but rule-breaking in the others?), burden the user with choosing (which would be hell if there are a lot), or simply make it read-only. I don’t really like any of these. It also raises hairy questions about who will control which communities are and are not part of the group, how the groupings react to defeds, etc.
Just block it
We can share block list, preferably automatic consensus blocklists and gradual deamplification list. The alternative is the current default which as if they were all already blocked, except the one big one.
Allow communities that contain the same content but exist on different instances to show each others content as if they were one community.
That sounds like it’d be fantastic for reading but, depending on how it’s implemented, hell for posting.
Lemmy already aggregates posts from communities you follow into one feed. If it allowed the creation of an arbitrary number of sub-feeds configurable by the user, that would be incredible. But every user would have to build these on their own from scratch. Great for user choice, but no communities will come bundled by default, so small communities won’t get a discovery boost.
If instead there was some kind of first-class notion of a “supercommunity” offered on the server side, where it acted as a transparent view of other communities, that’d be a great visibility boost for small communities. But if you tried to post to it, which underlying community would it post to? You’d have to either designate a default community to receive posts (which would be unfair to every other community there), randomize where it goes to (which would be a quagmire, what if your post is allowed in half of the communities present but rule-breaking in the others?), burden the user with choosing (which would be hell if there are a lot), or simply make it read-only. I don’t really like any of these. It also raises hairy questions about who will control which communities are and are not part of the group, how the groupings react to defeds, etc.
I believe there was a new threadiverse software that has build what you describe. But I can’t remember the name.
Like multireddits on that other site
Except multireddit were not shared accross users, making them largely irrelevant.
On lemmy, the default view should be, if you go to /c/books, you get all books on all instances in a single place.
Anything less will suffer the same downfall as reddit
What if someone created a /c/books on their own instance with bad intentions, and filled it with propaganda, porn, and ads?
Just block it We can share block list, preferably automatic consensus blocklists and gradual deamplification list. The alternative is the current default which as if they were all already blocked, except the one big one.