I’ve noticed in the explosion that we are getting duplicate communities in multiple instances. This is ultimately gonna hinder community growth as eventually communities like ‘cats’ will exist in hundreds of places all with their own micro groups, and some users will end up subscribing to duplicates in their list.
A: could we figure out a system to let our communities know about the duplicates as a sticky so that users can better find each other?
B: I think this is the best solution, could a ‘super community’ method be developed under which communities can join or be parented to under that umbrella and allow us to subscribe to the super community under which the smaller ones nest as subs? This would allow the communities to stay somewhat fractured across multiple instances which can in turn protect a community from going dark if a server dies, while still keeping the broader audience together withing a syndicated feed?
Maybe something closer to migration management in mastodon? Two groups of moderators on separate servers agree to a common set of moderation guidelines, publish an event or setting which says “these communities are merging”, and from that point on they act like aliases for a merged community which share responsibility across servers.
These “merged” communities could be visually flagged as distinct from the normal rules / moderation of their respective servers to prevent conflicts arising from differences in server management.
Feature support would be limited by the server events are sourced from. E.g. if beehaw.org and lemmy.ml merged their technology communities, people on beehaw still wouldn’t be able to downvote posts or see downvotes, but lemmy.ml would unless they explicitly disable to feature as a part of the merge contract.
When subscribing, you might see a list of merged communities which share responsibility for moderating the final one, and you have the ability to choose which “entrypoint” you use.