So where is the development interest for less monolithic instance control then? Everything I read indicates a movement towards it, with less transparency that can be federated (like not allowing downvotes and moderation to truly be transparent and there’s no interest in making communities that aren’t localized to single instances by making its moderation be something that can be something that can be applied and decided at the user or each instance level.
This would also mean inherently allowing user participation in a community regardless of how much an instance doesn’t want it (as long as it is not their home instance, which would be the ones in charge of removing spam/bot/CSAM) if a particular selection of a moderation group does not allow it. Communities are monolithic by design, limited to an instance’s moderation and then to that instance’s administration and then furthermore by its availability.
I’m sure that the availability of time and effort are a factor, it would require dealing with new and different issues, it might require leaving some monolithic aspects, but it fails before it gets at that point, there is no interest nor is it where development wants to head. Communities are monolithic and will essentially remain monolithic. The only thing that is federated is essentially the search features and pseudo-SSO of Lemmy.
What you all mention here are valid issues and concerts. The point is that everything you mentioned is related on how the ActivityPub protocol works, which inherently create this situation of semi-decentralizing in form of instances and federation. If we want to get rid of that, we need a fully different protocol that resolves all your issues in a decentralized way, which isn’t always scaling, or leaking the technical advances to do so. Or you could even argue that ActivityPub is currently de facto standard (which also includes Mastodon, etc).
The only way to solve all the issues mentioned is to fully replace ActvityPub by another protocol. Which doesn’t relay on instances, and no DNS, and no global identity… Which are technically very challenging subjects on its own. Fediverse is well… federated, but not decentralized.
Disclaimer: I’m the developer of Mbin project. And previous contributor of kbin.
And thanks for the work in your branch, it has kept mbin alive. As I understand it, ActivityPub is an open standard for relaying information that is distinct from how the back-end operates, and it operates with very generic concepts like Objects, Activites, and Actors, so I suspect it can be adapted even if I don’t know it to the degree that you do. Each user could engage in a community and their contribution would be treated as a multicast hosted on the home instance which the rest of the servers could pick up and update on their end, for example.
Querying for comments and posts in a community could first return local and then the cached for remote content that would update on demand, delaying if necessary, applying the implementation specific decentralization mechanism of choice. Maybe Librecast would be an option, I don’t know any-end. Moderation could be applied to the result as a personal preference and in multiple layers by choosing which moderator activities and groups you would accept or ignore, and moderator groups could be treated as entities owned and coordinated by their leaders.
Users behaves badly, user is removed. Instance does not want to deal with certain users from other instances, they block them. They could coordinate general admin decisions between instances, they just would manifest direct control over communities. If they don’t like how certain communities behave, they would have options, they just wouldn’t have complete control and communities could criticize the application of those options without compromising their entire being. Instances could ban misinformation, but what one instance considers misinformation another might not. Moderators could become trusted instance enforcers and automatically help enforce misinformation filters for the instance groups they cooperate with. It would basically be another layer of abstraction between the community and the host moderators.
Communities could accommodate different schools of thought within the same community and without each other calling the other troll and banishing their participation, one would just have to shift between the moderator groups they want. Instances could step in, but exceptionally, making people’s choice of instance matter more. It would be extremely easy to set up a ground.news social network alternative in this context that wouldn’t have to devolve into two extremes, but things like downvotes and mod actions would have to be transparent because of how dynamic and customizable the system would have to be.
The problem in the software world isn’t usually that there is no choice, it’s that there is no will. The obstacles are not insurmountable, there’s just no interest in overcoming them I think. I know you can speak for yourself, but I don’t think you can speak for the main lemmy (lemmy.ml) devs, mbin is already much more transparent than lemmy is.
So where is the development interest for less monolithic instance control then? Everything I read indicates a movement towards it, with less transparency that can be federated (like not allowing downvotes and moderation to truly be transparent and there’s no interest in making communities that aren’t localized to single instances by making its moderation be something that can be something that can be applied and decided at the user or each instance level.
This would also mean inherently allowing user participation in a community regardless of how much an instance doesn’t want it (as long as it is not their home instance, which would be the ones in charge of removing spam/bot/CSAM) if a particular selection of a moderation group does not allow it. Communities are monolithic by design, limited to an instance’s moderation and then to that instance’s administration and then furthermore by its availability.
I’m sure that the availability of time and effort are a factor, it would require dealing with new and different issues, it might require leaving some monolithic aspects, but it fails before it gets at that point, there is no interest nor is it where development wants to head. Communities are monolithic and will essentially remain monolithic. The only thing that is federated is essentially the search features and pseudo-SSO of Lemmy.
What you all mention here are valid issues and concerts. The point is that everything you mentioned is related on how the ActivityPub protocol works, which inherently create this situation of semi-decentralizing in form of instances and federation. If we want to get rid of that, we need a fully different protocol that resolves all your issues in a decentralized way, which isn’t always scaling, or leaking the technical advances to do so. Or you could even argue that ActivityPub is currently de facto standard (which also includes Mastodon, etc).
The only way to solve all the issues mentioned is to fully replace ActvityPub by another protocol. Which doesn’t relay on instances, and no DNS, and no global identity… Which are technically very challenging subjects on its own. Fediverse is well… federated, but not decentralized.
Disclaimer: I’m the developer of Mbin project. And previous contributor of kbin.
And thanks for the work in your branch, it has kept mbin alive. As I understand it, ActivityPub is an open standard for relaying information that is distinct from how the back-end operates, and it operates with very generic concepts like Objects, Activites, and Actors, so I suspect it can be adapted even if I don’t know it to the degree that you do. Each user could engage in a community and their contribution would be treated as a multicast hosted on the home instance which the rest of the servers could pick up and update on their end, for example.
Querying for comments and posts in a community could first return local and then the cached for remote content that would update on demand, delaying if necessary, applying the implementation specific decentralization mechanism of choice. Maybe Librecast would be an option, I don’t know any-end. Moderation could be applied to the result as a personal preference and in multiple layers by choosing which moderator activities and groups you would accept or ignore, and moderator groups could be treated as entities owned and coordinated by their leaders.
Users behaves badly, user is removed. Instance does not want to deal with certain users from other instances, they block them. They could coordinate general admin decisions between instances, they just would manifest direct control over communities. If they don’t like how certain communities behave, they would have options, they just wouldn’t have complete control and communities could criticize the application of those options without compromising their entire being. Instances could ban misinformation, but what one instance considers misinformation another might not. Moderators could become trusted instance enforcers and automatically help enforce misinformation filters for the instance groups they cooperate with. It would basically be another layer of abstraction between the community and the host moderators.
Communities could accommodate different schools of thought within the same community and without each other calling the other troll and banishing their participation, one would just have to shift between the moderator groups they want. Instances could step in, but exceptionally, making people’s choice of instance matter more. It would be extremely easy to set up a ground.news social network alternative in this context that wouldn’t have to devolve into two extremes, but things like downvotes and mod actions would have to be transparent because of how dynamic and customizable the system would have to be.
The problem in the software world isn’t usually that there is no choice, it’s that there is no will. The obstacles are not insurmountable, there’s just no interest in overcoming them I think. I know you can speak for yourself, but I don’t think you can speak for the main lemmy (lemmy.ml) devs, mbin is already much more transparent than lemmy is.