dessalines
commented
1 week ago This doesn't make much sense to me, because communities aren't active actors in the way users are, they're a space people can post to. Communities don't need to subscribe to other communities because they don't need to read anything, its the users who do.
This proposal would be for communites to opt in to federating with other communities to receive their posts.
This sounds like grouping communities, so #818 is a better solution to this problem.
Requirements
Is your proposal related to a problem?
Less than being a solution to a problem, it is an elevation of federation to be not just at the server level, but at the community level.
One issue with Lemmy federation is that the communities are completely separated, resulting in users subbing to the same community across multiple servers and posting to multiple communities across multiple servers.
This proposal would be for communites to opt in to federating with other communities to receive their posts
Describe the solution you'd like.
Naive implementation: When a post, comment, like, removal/mod action is received by a recipient server, it looks up that community's federated communities and publishes there as well. This new post should have a source community id to referenc the original community.
The downside of this approach is data duplication. The upside is potentially easier implementation
Re-using existing data: A query to get posts from one community, ie CoolStuff@lemm.ee, when CoolStuff@lemm.ee is federated with CoolStuff@lemmy.world returns posts from both lemm.ee and lemm.world.
The federated post shows to the user that it is actually from CoolStuff@lemmy.world
Community Fedration is receive only: If community B chooses to federate with Community A, then community B will receive community A's posts, but A will not receive B's posts until A federates with B.
User Blocks: A user can choose to not show federated posts from a community via the UI sidebar, which would have a selectable list of federated communities that were chosen by the mods. By default, all would be chosen.
Mod Actions from source: A mod action, such as deleting a post or comment can be received by the federating community and mimic'd there. Alternatively, a more advanced set of options can be implemented later to allow for automatic propagation or mod approval for certain actions.
Mod Actions from federating community: Would stay local and not propagate to the source. However, similar rules as above could apply for source comments. Scenario: when community B receives a post and comment from community A, then a user on B makes a comment, that comment can federate to A (should A be federated to B as well)
Describe alternatives you've considered.
I did look at a proposal to add a new activity pub message type, but I think that we can get around needing that.
If the Naive implementation is used, a lot of existing code could potentially be re-used at the sacrifice of storage. The second approach would have to have another way of storing posts and comments that reference a post from another community and would be more work.
Additional context
Would require (minimum) two new database tables: FederatedCommunities(LocalCommunityId, RemoteCommunityId) UserFederatedCommunityFilters(LocalUserId, FilteredCommunityId)
This would not include any automatic or configurable mod actions.