The problem of which instance to host a community on is a big problem for Lemmy. Grouping is an interesting idea but it causes problems as now there are different mods and admins that control subsets of the community.
Picking a single “winner” and letting the others wither seems like the right approach and will probably happen naturally but if the original instance ever shuts down or struggles under the load you will have a mess to migrate to a new instance.
If Lemmy communities were decentralized it would make a huge difference. You could just have a single community but it could survive instances coming and going (as well as many other performance and resiliency benefits). But that would be a huge change to the underlying implementation of communities.
The problem of which instance to host a community on is a big problem for Lemmy.
Seeing the same content posted six times in six communities is a problem. It pollutes the feeds, it fragments the conversation, and prevents the natural death of low-traffic communities.
I disagree. Grouping communities makes sense if they need the same admin policy. Admin policy sets a floor on what mods are required to police when it comes to things like hate speech and threats, but mods in a programming community aren’t going to allow that shit anyway, so admin policy is irrelevant.
Yup, I’m actually interested in working on a truly decentralized lemmy. Basically, I want to use IPFS or Iroh to have it completely decentralized across all users’ machines.
However, the big problem remains the same: how does moderation work? With lemmy, you can always go to the instance admin if your mods suck, but if it’s completely decentralized, you need some other mechanism. Also with lemmy, if a community starts sucking, there’s usually enough redundancy that you can just go to another major instance and find a similar community, but if it’s decentralized, I think you’ll have the Reddit problem where you’ll essentially have to get a large chunk of the community to move if there’s an issue.
So I’m not convinced that decentralization is the right way to go, at least until the problem of moderation is resolved. Maybe I’ll try building a decentralized instance, which is largely intended to solve the issue of scaling, but I don’t think a decentralized platform would be a good replacement for lemmy.
Mod actions could be cryptographically signed using a private keys, and the public keys of the mods would be part of each community’s metadata, updated in a way that establishes a chain of custody so only existing mods can add new mods. Each instance would independently verify that mod actions come from a legitimate mod. (I think I basically just described an implementation of NTFs representing mod privileges, BTW.)
That sounds like a blockchain with signature verification against a previously established and acknowledged set of keys as consensus mechanism. Pretty reasonable, as far as use cases go.
However, it doesn’t solve the issue of disagreements and community splitting. If one part of the mod team decides to add another mod, but the rest doesn’t, what’s to prevent that part from splitting off and continuing their own version of the moderation chain? How is abuse of power handled? And in case of a split, how are community members informed?
Don’t get me wrong, I’m not saying it’s a poor idea, I’m just saying that it won’t solve the issues of community splits, and I’m not sure anything ever can.
I wasn’t trying to solve that particular problem, on the assumption that it has already been solved and the same solution can be adapted to the implement I proposed. Someone else who replied to me suggested something like requiring majority approval to add or remove a mod.
Another possibility is for the creator of a community to be a super mod, who can add or remove regular mods, or transfer their super mod status to someone else. That scheme could easily be generalized to allow multiple super mods, or to include a whole hierarchy of mods for large communities.
I prefer it to have multiple mods, ideally a majority. That way, you can’t have one mod “go rogue” and add a bunch of alts or whatever, which also means a mod account getting compromised can’t “go rogue.”
I’m less concerned about mod actions like deleting posts, banning users, etc, since mod actions should always be able to be rolled back since most decentralized systems use immutable data (so a mod action is merely data that instructs clients to ignore or prefer certain other data). However, I don’t want a situation where mods become powerless because one of their accounts got compromised.
I’m not concerned here about the rules for how mods are added or removed, just the technical implementation. It’s easy enough to require a majority for decisions like that.
There has to be a way to establish with certainty that a user taking mod actions is actually a mod. The fact that you can revert changes in a git repo doesn’t make it ok for people to commit without permission, and mod actions are the same. Just allowing unauthorized users to perform mod actions would allow them to fuck up communities faster than the real mods could undo the damage.
The problem of which instance to host a community on is a big problem for Lemmy. Grouping is an interesting idea but it causes problems as now there are different mods and admins that control subsets of the community.
Picking a single “winner” and letting the others wither seems like the right approach and will probably happen naturally but if the original instance ever shuts down or struggles under the load you will have a mess to migrate to a new instance.
If Lemmy communities were decentralized it would make a huge difference. You could just have a single community but it could survive instances coming and going (as well as many other performance and resiliency benefits). But that would be a huge change to the underlying implementation of communities.
Seeing the same content posted six times in six communities is a problem. It pollutes the feeds, it fragments the conversation, and prevents the natural death of low-traffic communities.
Avoiding showing identical posts to a user separately seems like a very easy problem to solve.
I think it probably makes sense to host similarly moderated content together.
programming content being grouped together makes sense because it’s moderated to a similar extent between languages and communities.
For example discussions/posts on rust programming and porn are moderated very differently, so they should be on different instances.
I disagree. Grouping communities makes sense if they need the same admin policy. Admin policy sets a floor on what mods are required to police when it comes to things like hate speech and threats, but mods in a programming community aren’t going to allow that shit anyway, so admin policy is irrelevant.
Yup, I’m actually interested in working on a truly decentralized lemmy. Basically, I want to use IPFS or Iroh to have it completely decentralized across all users’ machines.
However, the big problem remains the same: how does moderation work? With lemmy, you can always go to the instance admin if your mods suck, but if it’s completely decentralized, you need some other mechanism. Also with lemmy, if a community starts sucking, there’s usually enough redundancy that you can just go to another major instance and find a similar community, but if it’s decentralized, I think you’ll have the Reddit problem where you’ll essentially have to get a large chunk of the community to move if there’s an issue.
So I’m not convinced that decentralization is the right way to go, at least until the problem of moderation is resolved. Maybe I’ll try building a decentralized instance, which is largely intended to solve the issue of scaling, but I don’t think a decentralized platform would be a good replacement for lemmy.
Mod actions could be cryptographically signed using a private keys, and the public keys of the mods would be part of each community’s metadata, updated in a way that establishes a chain of custody so only existing mods can add new mods. Each instance would independently verify that mod actions come from a legitimate mod. (I think I basically just described an implementation of NTFs representing mod privileges, BTW.)
That sounds like a blockchain with signature verification against a previously established and acknowledged set of keys as consensus mechanism. Pretty reasonable, as far as use cases go.
However, it doesn’t solve the issue of disagreements and community splitting. If one part of the mod team decides to add another mod, but the rest doesn’t, what’s to prevent that part from splitting off and continuing their own version of the moderation chain? How is abuse of power handled? And in case of a split, how are community members informed?
Don’t get me wrong, I’m not saying it’s a poor idea, I’m just saying that it won’t solve the issues of community splits, and I’m not sure anything ever can.
I wasn’t trying to solve that particular problem, on the assumption that it has already been solved and the same solution can be adapted to the implement I proposed. Someone else who replied to me suggested something like requiring majority approval to add or remove a mod.
Another possibility is for the creator of a community to be a super mod, who can add or remove regular mods, or transfer their super mod status to someone else. That scheme could easily be generalized to allow multiple super mods, or to include a whole hierarchy of mods for large communities.
I prefer it to have multiple mods, ideally a majority. That way, you can’t have one mod “go rogue” and add a bunch of alts or whatever, which also means a mod account getting compromised can’t “go rogue.”
I’m less concerned about mod actions like deleting posts, banning users, etc, since mod actions should always be able to be rolled back since most decentralized systems use immutable data (so a mod action is merely data that instructs clients to ignore or prefer certain other data). However, I don’t want a situation where mods become powerless because one of their accounts got compromised.
I’m not concerned here about the rules for how mods are added or removed, just the technical implementation. It’s easy enough to require a majority for decisions like that.
There has to be a way to establish with certainty that a user taking mod actions is actually a mod. The fact that you can revert changes in a git repo doesn’t make it ok for people to commit without permission, and mod actions are the same. Just allowing unauthorized users to perform mod actions would allow them to fuck up communities faster than the real mods could undo the damage.