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.
I think you’re now suggesting things that have nothing to do with consolidating communities.
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.
They don’t exists right now, but the foundation is there. I checked the old kbin.social communities that users from lemm.ee had subscribed to. All the posts seem to be there right until kbin.social got shut down. The data exists on your instance even if the original instance went down. It’s just a matter of figuring out and creating a new functionality to revive those communities on a new instance. This suggestion has nothing to do with consolidation, it’s just a backup solution that can already be done.
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 see how that specifically requires a ledger but I guess we can call it a ledger. The solution itself is fairly simple, each instance publishes whenever a new community is created or deleted and federated instances can store that data on their side to have a list of all the communities to search for. For already existing we can create a “publish all existing communities” so each instance can update their lists accordingly. That’s effectively a ledger but once again, it has nothing to do with consolidating communities.
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.
Distributed consensus is a concept but is such complexity necessary? Especially when the end result isn’t that much different to what we already have.
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.
It can, but it doesn’t really matter because that’s exactly how the current system works. As for migrations, if we solve the “backup community” problem then that functionality can just as well be used for migrations because right now we can just duplicate data. If you want to add the one community restriction that migration actually gets harder to implement.
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.
Kbin/Mbin integrations with Lemmy worked pretty well, but if you force all Lemmy instances to use a solution unique to Lemmy then you’re pretty much building a wall because integrations with other similar implementations become less likely. Nobody owns the wall but it would create an “in” group and an “out” group. We already kinda have that with Lemmygrad and Hexbear and the rest of Lemmy, but those two instances can exists independently from the rest of Lemmy so the “in” and “out” groups can easily coexists. But if you force communities across instances you’re going to also force friction between the “in” and “out” groups. There can only be one “c/europe” but there’s one on Lemmygrad and there’s also one on feddit. If you keep the feddit one then Lemmygrad and Hexbear can’t have c/europe and if you let Lemmygrad have c/europe then the rest of Lemmy can’t have c/europe. It’s unnecessary friction.
I guess it would work if Lemmygrad and Hexbear were federated with the rest of Lemmy, but that’s not happening.
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.
I think you’re now suggesting things that have nothing to do with consolidating communities.
They don’t exists right now, but the foundation is there. I checked the old kbin.social communities that users from lemm.ee had subscribed to. All the posts seem to be there right until kbin.social got shut down. The data exists on your instance even if the original instance went down. It’s just a matter of figuring out and creating a new functionality to revive those communities on a new instance. This suggestion has nothing to do with consolidation, it’s just a backup solution that can already be done.
I don’t see how that specifically requires a ledger but I guess we can call it a ledger. The solution itself is fairly simple, each instance publishes whenever a new community is created or deleted and federated instances can store that data on their side to have a list of all the communities to search for. For already existing we can create a “publish all existing communities” so each instance can update their lists accordingly. That’s effectively a ledger but once again, it has nothing to do with consolidating communities.
Distributed consensus is a concept but is such complexity necessary? Especially when the end result isn’t that much different to what we already have.
It can, but it doesn’t really matter because that’s exactly how the current system works. As for migrations, if we solve the “backup community” problem then that functionality can just as well be used for migrations because right now we can just duplicate data. If you want to add the one community restriction that migration actually gets harder to implement.
Kbin/Mbin integrations with Lemmy worked pretty well, but if you force all Lemmy instances to use a solution unique to Lemmy then you’re pretty much building a wall because integrations with other similar implementations become less likely. Nobody owns the wall but it would create an “in” group and an “out” group. We already kinda have that with Lemmygrad and Hexbear and the rest of Lemmy, but those two instances can exists independently from the rest of Lemmy so the “in” and “out” groups can easily coexists. But if you force communities across instances you’re going to also force friction between the “in” and “out” groups. There can only be one “c/europe” but there’s one on Lemmygrad and there’s also one on feddit. If you keep the feddit one then Lemmygrad and Hexbear can’t have c/europe and if you let Lemmygrad have c/europe then the rest of Lemmy can’t have c/europe. It’s unnecessary friction.
I guess it would work if Lemmygrad and Hexbear were federated with the rest of Lemmy, but that’s not happening.