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.
Yeah, I agree. All mod actions should be signed by their cryptographic key, and moderator cryptographic keys should probably be separate and stronger than regular user cryptographic keys. Mod actions should be rare enough that this isn’t a burden to verify.
One thing I’m not as sure about is if the data is decentralized as well, users would potentially be liable for illegal content. I suppose there could be a system that moderator-removed content gets removed from all regular users’ devices, so maybe that’s good enough. But then that makes auditing mod actions difficult, since the original data could be much harder to get.
A lot of these problems aren’t really technical, but rather UX when designing for a fully decentralized system.
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.
Yeah, I agree. All mod actions should be signed by their cryptographic key, and moderator cryptographic keys should probably be separate and stronger than regular user cryptographic keys. Mod actions should be rare enough that this isn’t a burden to verify.
One thing I’m not as sure about is if the data is decentralized as well, users would potentially be liable for illegal content. I suppose there could be a system that moderator-removed content gets removed from all regular users’ devices, so maybe that’s good enough. But then that makes auditing mod actions difficult, since the original data could be much harder to get.
A lot of these problems aren’t really technical, but rather UX when designing for a fully decentralized system.