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.

[–] [email protected] 5 points 1 year ago (12 children)

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.

[–] [email protected] 0 points 1 year ago (5 children)

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.)

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

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.

load more comments (3 replies)

load more comments (9 replies)

load more comments (14 replies)