But that’s effectively what we’ll have right now. You can create multiple communities of the same name but one will eventually become the main community that people will visit. And we could already create “backup” communities because I’m pretty sure the data from the main community is already sent to all the instances that have users who are subscribed to said community. The data is already in other instances, it’s just a matter of reusing the data.
So the only crux of your solution is how the possible instance for the community would be chosen. And that’s a whole can of worms. It can’t be the same instance the community creator is a part of because that’s the solution we have right now. It can’t be completely random because I’m pretty sure there are instances that legally can’t have porn or piracy on their instance, or maybe the instance owner simply doesn’t want that on their instance. If there’s supposed to be distributed ledger that effectively prevents creating duplicate communities and that ledger is the same for all instances, then there must be a possibility that the new community ends up in an instance the community creators instance might be defederated from, otherwise a “pariah” instance (who are pretty much defederated from the majority of Lemmy) can reserve community names by defederating everyone and then creating communities. So that decision starts to have a lot factors which lets instances influence the decision. And in some ways there’s even an incentive to influence the decision because the more communities one instance has the more power they have over the entire lemmy side of the fediverse. If they defederate from another instance that instance can’t create those communities for the people on that instance (unless you go down the reddit route of having gaming vs games vs truegames).
And that’s just the decision of the primary source. There’s a whole other bucket of questions about the distributed ledger. For example how does the ledger change? If one community needs to be moved to a different instance who makes that decision? If it’s the primary source instance then how do other instances verify the ledger? If you have Instances A, B, C and C and instances A and B are defederated from C. Instance A has a community that gets assigned to instance D. Instance A sends a ledger change to instances B and D and then instance D send the change to C, but how does instance C know that the sent data is correct? Instance D could send the message that instance A set the community to instance B and there’s no way for instance C to verify that message. In fact most of my questions in my previous comment apply to the ledger as well because the ledger would have to exists on every instance.
And then there are other factors like what if Mbin sets up a community/magazine? Mbin doesn’t care about any ledger. Will we turn Lemmy into a walled garden and prevent Mbin from participating because they don’t want our ledger?
Backup communities don’t really exist right now. There are copies of things on other servers l, but they can’t become functioning communities. This has caused some communities to disappear when their instance went down. The biggest I remember is movies and TV related things.
Having a ledger helps with discovery, because instances now don’t know about other communities by default, it requires extra effort to seek them out until someone else has found them and subscribed. It’s not a big deal for established communities, but it does hurt building a new one.
I don’t have a great solution for admin of creation/movement of communities, but this isn’t meant to be a 100% solution. Distributed consensus is a concept that exists though. There’s no reason a community can’t go on a users instance as default, it just enables a community to potentially migrate for various reasons.
This doesn’t necessarily create a walled garden, as no one owns the walls. It does encourage everyone within Lemmy to maximally federate. I can’t say it significantly changes integration with other implementations as they were never very robust in the first place.
But that’s effectively what we’ll have right now. You can create multiple communities of the same name but one will eventually become the main community that people will visit. And we could already create “backup” communities because I’m pretty sure the data from the main community is already sent to all the instances that have users who are subscribed to said community. The data is already in other instances, it’s just a matter of reusing the data.
So the only crux of your solution is how the possible instance for the community would be chosen. And that’s a whole can of worms. It can’t be the same instance the community creator is a part of because that’s the solution we have right now. It can’t be completely random because I’m pretty sure there are instances that legally can’t have porn or piracy on their instance, or maybe the instance owner simply doesn’t want that on their instance. If there’s supposed to be distributed ledger that effectively prevents creating duplicate communities and that ledger is the same for all instances, then there must be a possibility that the new community ends up in an instance the community creators instance might be defederated from, otherwise a “pariah” instance (who are pretty much defederated from the majority of Lemmy) can reserve community names by defederating everyone and then creating communities. So that decision starts to have a lot factors which lets instances influence the decision. And in some ways there’s even an incentive to influence the decision because the more communities one instance has the more power they have over the entire lemmy side of the fediverse. If they defederate from another instance that instance can’t create those communities for the people on that instance (unless you go down the reddit route of having gaming vs games vs truegames).
And that’s just the decision of the primary source. There’s a whole other bucket of questions about the distributed ledger. For example how does the ledger change? If one community needs to be moved to a different instance who makes that decision? If it’s the primary source instance then how do other instances verify the ledger? If you have Instances A, B, C and C and instances A and B are defederated from C. Instance A has a community that gets assigned to instance D. Instance A sends a ledger change to instances B and D and then instance D send the change to C, but how does instance C know that the sent data is correct? Instance D could send the message that instance A set the community to instance B and there’s no way for instance C to verify that message. In fact most of my questions in my previous comment apply to the ledger as well because the ledger would have to exists on every instance.
And then there are other factors like what if Mbin sets up a community/magazine? Mbin doesn’t care about any ledger. Will we turn Lemmy into a walled garden and prevent Mbin from participating because they don’t want our ledger?
Backup communities don’t really exist right now. There are copies of things on other servers l, but they can’t become functioning communities. This has caused some communities to disappear when their instance went down. The biggest I remember is movies and TV related things.
Having a ledger helps with discovery, because instances now don’t know about other communities by default, it requires extra effort to seek them out until someone else has found them and subscribed. It’s not a big deal for established communities, but it does hurt building a new one.
I don’t have a great solution for admin of creation/movement of communities, but this isn’t meant to be a 100% solution. Distributed consensus is a concept that exists though. There’s no reason a community can’t go on a users instance as default, it just enables a community to potentially migrate for various reasons.
This doesn’t necessarily create a walled garden, as no one owns the walls. It does encourage everyone within Lemmy to maximally federate. I can’t say it significantly changes integration with other implementations as they were never very robust in the first place.